10 ms·
BuckleScript: write JavaScript faster, safer and smaller
- bootload 10y ago"BuckleScript is one of the very few compilers which compiles an existing typed language to readable JavaScript." Elm (type inference) is sort of. While there is a lot of OS type projects used, having bloomberg use it is a plus. Interesting that FB have build system ^Reason^ (build system) doing something similar (OCaml backend->JS) ~ http://facebook.github.io/reason/ http://facebook.github.io/reason/
- yawaramin 10y agoReason is an alternative, JavaScript-like, syntax for the OCaml language. Same language, different syntax! It's crazy cool. BuckleScript is an OCaml -> ES5 compiler, so it actually compiles Reason to ES5 just fine. Bloomberg and Facebook are two big users of BuckleScript. FB have a couple of folks writing significant stuff in Reason, compiling with BuckleScript, and deploying to user-facing web properties.
- deleted 10y ago[deleted]
- k__ 10y agoWhat is the difference between reason and bucklescript?
- phpnode 10y agoReason is a language, bucklescript is an alternative backend for ocaml which generates JavaScript. You write reason, you don't write bucklescript
- k__ 10y agookay, then what's the difference between ocaml and reason? :)
- phpnode 10y agoReason is a js like syntax for ocaml, semantically they're identical. Similar to coffeescript and JavaScript, except ocaml has really good support for this kind of stuff
- nerdponx 10y agoSo what you're saying is I could write a JavaScript-esque program and compile it to OCaml using Reason, and then compile it to true JavaScript using Bucklescript?
- phpnode 10y agoYes exactly, although you can avoid the middle step and go straight from reason to js because of the way bucklescript plugs into the ocaml compiler
- e12e 10y agoWhy would one prefer reason to ocaml? (Honest question)
- purity_resigns 10y agoReason's syntax is a little cleaner and it's easier to get up and running with.
- phpnode 10y agoIt is much more like JavaScript than ocaml and so you get a familiar language but one which benefits from all the cool things that ocaml can do.
- 10y ago
- akhilcacharya 10y agoI'm still waiting on full JSX and React for BuckleScript.
- quicksnap 10y agoJSX is available in Reason out of the box: https://facebook.github.io/reason/#diving-deeper-jsx https://facebook.github.io/reason/#diving-deeper-jsx
- akhilcacharya 10y agoOh snap, didn't know this was supported yet. I think the tooling isn't available for transforming Reason => JSX in a consistent development environment from what I gather, but I haven't paid attention for a few months.
- cel1ne 10y agoKotlin can do that too: https://kotlinlang.org/ https://kotlinlang.org/
- agumonkey 10y agoKotlin is slow though. To compile that is.
- SureshG 10y agoDartlang dev compiler - https://github.com/dart-lang/sdk/tree/master/pkg/dev_compiler https://github.com/dart-lang/sdk/tree/master/pkg/dev_compile... .
- wstrange 10y agoDDC is an alternative to the dart2js compiler. It supports "strong mode" which provides better compile time checking, and produces more idiomatic Javascript. Dart has a large team behind it, an awesome package management infrastructure, a "Dart native" angular 2 library.
- willtim 10y agoDart is just another junk food programming language in the same vein as Java (with some of the same people involved). If you really want to learn what a "strong mode" is, learn OCaml. Good job Bloomberg for Bucklescript.
- teen 10y agodidn't gwt do this 5 years ago
- grayrest 10y agoIf we're just talking about compiling a typed language to javascript, gwt did it 12 years ago.
- bootload 10y ago"Interesting that FB have build system ^Reason^ (build system)" One reason to define a tool and use language clearly, I interpreted, 'Build Systems Rapidly' as a ^build system^ where in reality Reason is a ^systems language^ to build things quickly. Some of the tools are fantastic. I would love to have REFMT "dynamically as the window resizes in order to make optimal use of screen real estate while still abiding perfectly by the formatting rules" built into language editors to aid development.
- grandalf 10y agoI think BuckleScript is going to blow up one of these days and become hugely popular.
- fspeech 10y agoI am waiting for the next Windows release that would allow one to use the bash subsystem from native programs so I can use Reason/BuckleScript with Vscode. OCaml/Windows integration isn't the greatest.
- baq 10y agoyou should be able to use linux VSCode with a win32 X server like mobaxterm right now.
- yawaramin 10y agoBuckleScript itself works fine on Windows. Installs in an npm project with `npm install bs-platform` and good to go from there. Try it out.
- fspeech 10y agoI can run BuckleScript under Windows/Bash. However as I understand it one needs things like merlin working to get a decent IDE experience.
- buzzybee 10y agoOoh, I wonder this could lead to the Haxe compiler running in JS.
- dochtman 10y agoWell, Rust can compile to asm.js or wasm, too. Might still be rough around the edges, but it will improve soon enough.
- chrismorgan 10y agoRust compilation is slow, and the compilation target opaque. BuckleScript is fast, and compiles to readable JavaScript. Please don’t just go spouting that Rust is the answer to everything; it’s not. It’s also not always relevant in a discussion. (I say this as someone who is lauding Rust at every turn and who has been using it seriously for years and who is looking forward to a solid wasm target and ecosystem.)
- dochtman 10y agoSorry, my post maybe came off as more negative than I intended, but the downvotes seem a bit harsh. To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned. Readable JavaScript is not as important as long as we have source maps, which WebASM was designed to take into account. Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript, which IMO is worth the longer compile cycles. I think Rust is relevant because Ocaml and Rust share a lot of heritage (indeed, I think Ocaml was one of the most influential languages in the Rust design), so I think that makes it relevant in this discussion.
- sjrd 10y agoThe problem with wasm right now is that it gives you very little in terms of interoperability with JavaScript. You simply cannot manipulate JS objects (including DOM objects) from wasm. Compiling a language like BuckleScript to wasm is therefore not possible at the moment, simply because the interop features of BuckleScript cannot be encoded in wasm. Besides, there are other difficulties: wasm doesn't have any kind of managed heap at the moment, which means that compiling a managed language to wasm requires to embed an entire GC in your production code! It's much better to take advantage of all the VM features offered to JS, like a GC, when compiling a managed language to the Web platform.
- hazza1 10y agoBuckleScript looks great but I've never found any project using it - maybe Reason will be the tooling to make it mainstream?
- bobbbi 10y agoProjects in Bucklescript do exist, here's one that shows how easy it is to integrate with JS - https://github.com/paulhoughton/montecarlo/ https://github.com/paulhoughton/montecarlo/ Or lots of examples here - https://github.com/OvermindDL1/bucklescript-testing https://github.com/OvermindDL1/bucklescript-testing
- yawaramin 10y agoI wrote up a non-technical post about my experience with BuckleScript http://yawar.blogspot.ca/2017/01/bucklescript-significant-new-ocaml-to.html http://yawar.blogspot.ca/2017/01/bucklescript-significant-ne...
- willtim 10y agoI found a page explaining the differences between bucklescript and js_of_ocaml : https://github.com/bloomberg/bucklescript/wiki/Differences-from-js_of_ocaml https://github.com/bloomberg/bucklescript/wiki/Differences-f...
- sheerun 10y agoCould somebody compile Flow to JavaScript?
- phpnode 10y agoThe flow parser is already available in js, it doesn't seem impossible to bring the rest of it to the browser but I'm not aware of anyone working on it
- djsumdog 10y agoThis looks pretty interesting. It makes me want to learn OCaml. :-P I've been using Coffeescript in projects for about two years. I know people have raised issues with it vs ES6, but I still really like Coffeescript. I feels more natural with my Scala/Ruby background and it outputs into Javascript in ways that (mostly) make sense and are predictable.
- aikah 10y ago> This looks pretty interesting. It makes me want to learn OCaml. :-P You can learn F# with dotnet core, which has a better ecosystem for web development. OCaml is quite poor in that domain.
- KurtMueller 10y agoAre you speaking from experience? If so, do you have any or know of any resources I could look at? Also, what type of backend are you using with F# and dotnet core?
- ZenoArrow 10y agoIf you want the BuckleScript equivalent for F#, that would be Fable. https://github.com/fable-compiler/Fable/blob/master/README.md https://github.com/fable-compiler/Fable/blob/master/README.m... There's a newer branch called Fable Arch which I believe is focused on promoting the Elm Architecture for structuring web apps: https://github.com/fable-compiler/fable-arch https://github.com/fable-compiler/fable-arch FunScript is another alternative: http://funscript.info/ http://funscript.info/
- Paradigma11 10y agoI do not think that Arch is a newer branch but a framework that uses the standard fable compiler.
- elbear 10y agoElm Architecture for F# is Elmish: https://github.com/fable-compiler/fable-elmish https://github.com/fable-compiler/fable-elmish
- progx 10y agoLearn a language to program another language. Find the issue. (I did not say that BuckleScript is bad, i have only a problem with all kind of these tools)
- paxcoder 10y agoThe issue is having to go through that other language. So your problem is JavaScript's monopoly, right?
- klibertp 10y agoThere's no issue, as long as you know both languages. Which you should anyway - both JS and OCaml are interesting in their own right.
- yakshaving_jgt 10y agoHow is there an issue at all? Most languages people use compile down to something else. You don't need to know assembly to write Ruby.
- innocentoldguy 10y agoI cannot speak for the parent, but the difference for me is this: Matz wrote Ruby, for instance, because he felt that Perl lacked some features/capabilities that he wanted. This is good, and from this perspective, I have no complaints. Now, if Matz wrote Ruby to compile down to Perl, then it becomes an issue. At that point, Ruby wouldn't really be a new language, but just a Bandaid to hide the weaknesses and blemishes of Perl, for instance. Fundamentally, I would still be writing Perl, and that, for me, is where it becomes an issue, because I really haven't solved anything. I've just disguised it. My opinion on the matter is that Javascript sucks. We all know it sucks too, which is why things like Elm, CoffeeScript, ClojureScript, TypeScript, BuckleScript, Scala.js, etc. exist. We want to fix Javascript because we understand that it sucks; therefore, we tend to embrace these various attempts to make it less stupid. The solution to the problem, in my mind, isn't yet another Javascript transpiler though, but rather native support for superior languages. I'd like to see an API built into browsers to make them language agnostic. I think that would go a long way towards making web programming less lame. It may also give us a chance to clean up the DOM.
- david-given 10y agoThis looks really interesting. Does this implement the entire OCaml language? I found a section of the docs marked 'semantic differences', but it seems... suspiciously small... This would allow me to write GWT-style client/server apps where both ends are written in the same language with a set of common library code compiled for both, right? What's the library support like? Don't suppose there's any ELM-style DOM diffing support, is there?
- hongbo_zhang 10y agoYes, we implement the whole language, except a very few places that is hard to due to the limitation of JS runtime. Exactly, client side/ server side in a single language. People are working on porting the Elm architecture to BuckleScript, they will be coming soon
- virtualwhys 10y agoFrom Why BuckleScript[1] Large JS output even for a simple program "In BuckleScript, a Hello world program generates 20 bytes JS code instead of 50K bytes. This is due to the fact that ... all BuckleScript’s runtime is written in OCaml itself so that these runtime libraries are only needed when user actually call it." What happens when you go beyond Hello World though? Surely there's some overhead vs. plain JS. For example, Hello World in Scala.js is tiny, but once you touch, say, the Scala collections library, then file size increases significantly. In the end, once you go beyond trivial applications, there's a 150KB baseline tax to pay for using the full power of Scala in the browser. If BuckleScript provides an OCaml-like language with file sizes comparable to plain JS that is both compelling and impressive. [1] http://bloomberg.github.io/bucklescript/Manual.html#_problems_of_javascript_how_bucklescript_solves_it http://bloomberg.github.io/bucklescript/Manual.html#_problem...
- hongbo_zhang 10y agoUnlike scalajs, bucklescript maps one OCaml module to one Js module, it is like coffecscript/typescript compilation model, there is no tax on the code size. You can write very clean code, here is an example of avl tree in ocaml compiled into JS(http://bloomberg.github.io/bucklescript/js-demo/#Balanced_tree http://bloomberg.github.io/bucklescript/js-demo/#Balanced_tr...)
- virtualwhys 10y ago^ that's completely ridiculous. Sounds like Reason can run the show as well (OCaml's crufty syntax has always bothered the SML'er in me), going to give this a look.
- sjrd 10y agoI like that BuckleScript has chosen the module-by-module design, if only to explore more design space than what was previously done in Scala.js and ClojureScript. I do not think this is what makes the 150 KB tax of Scala.js, though. The dead code elimination of Scala.js is really good, plus we combine it with Closure as well. But it faces a very difficult challenge: the entanglement of the Scala standard library. The collection library was designed when the JVM was the only target, and decoupling within the collections library was definitely not in the requirement set. This is why, once you touch the Scala collections library in Scala.js, you receive 150 KB worth of (non-gzipped) code. There is currently a large-scale effort to redesign the collections library for Scala 2.13 [1], with, among others, a desire to reduce inter-dependencies (while keeping most of user-level compatibility). This should hopefully significantly improve the situation of Scala.js regarding code size for smallish applications, as you will only pay for the collections you actually use; not the entire set of collections once you require one of them. [1] https://github.com/scala/collection-strawman https://github.com/scala/collection-strawman
- jxm262 10y agoBuilt in npm support is huge for me. I use Scalajs full time and one of my biggest issues is having to use SBT and webjars. I also end up using some mashup of npm modules as well later on in the build which complicates it even more. Plus the speed of the compiler becomes a massive issue, especially during unit tests. By turning it into a more readable Js, I wonder if the debugger would play more nicely too. I've noticed in Scalajs the debugger randomly misses breakpoints or moves to the wrong line sometimes. Anyway not a rant on Scalajs, I do like it but there's definitely some bottlenecks for me.
- yawaramin 10y agoI use Scala.js too. I haven't been able to set up a working sourcemap with our workflow of Scala.js -> Webpack -> JS. It's difficult to debug the mangled JS output but I can just about do it--barely. By contrast, reading BuckleScript's output JS is a breeze. No name mangling, idiomatic style, sensible code flow.
- sjrd 10y agonpm support is now available through https://scalacenter.github.io/scalajs-bundler/ https://scalacenter.github.io/scalajs-bundler/ I agree with your analysis on breakpoints and step-by-step in Scala.js. Usually it's a good idea to disable the Scala.js optimizer if you're doing that, using: scalaJSOptimizerOptions ~= { _.withDisableOptimizer(true) } But it's still not 100% perfect. I am toying with the idea that we should have a mode of the optimizer that tries to optimize for debuggability with step-by-step and breakpoints. This would try to arrange the generated source in closer relation with the source code (like, 1 line = 1 line). All of this is trying to work around limitations of source maps, and also of browsers' support for source maps. It would be so much easier if source maps were a little bit more powerful in what they can express (e.g., indicating what a "step" should be in the code).
- jxm262 10y agoThis bundler looks awesome sjrd, will give it a try soon. My other option I was going to suggest to other is to take a look at the sbt-web project. But keeping things compatible and seamless with npm I think is important since it's ubiquitous with front end devs
- 1_listerine_pls 10y agoAdvantages?
- coot_ 10y agohttp://www.purescript.org http://www.purescript.org - PureScript a small Haskell like programming language compiled to JavaScript (and C++)
- vorotato 10y agoFor those who need babel source maps there's Fable, it uses F# and Babel to generate javascript, OCaml and F# are remarkably similar.