4 ms·

Hi, the main author of BuckleScript here, below is a simple comparison with TypeScript (it may be biased): - Pros of TypeScript - Designed for JS, easy inte

Hi, the main author of BuckleScript here, below is a simple comparison with TypeScript (it may be biased): - Pros of TypeScript - Designed for JS, easy inter-operate with JS - A much larger community - Nice integration with VSCode - Cons of TypeScript - Compiler slow (not scalable for FB/Google scale) - Verbose, very limited type inference - Start up time slow (very hard to build traditional build tools) - Types are only used for tooling - soundness is not the design goal, not very reliable - Only JS backend, no code optimizations - Pros of BuckleScript - No legacy of JS (clean slate) while great story in inter-operation - Compiles much faster, scales much better 10% perf is a nice enhancement, 10x faster is an invaluable feature - An arguably much better language - Sound type system, global type inference - Types are used in code optimization, optimizing compiler - Javascript backend + Native backend for X86, ARM - Cons of BuckleScript - Smaller community - Learning curve is higher compared with TypeScript

vvanders 9y ago
> Compiler slow (not scalable for FB/Google scale) I don't have any dog in this fight(I write Java/Native mostly) however I'd don't quite follow what you mean by FB/Google scale. I would consider VSCode a pretty complex piece of software and my understand is it written in TS. Have any concrete numbers you can share that makes it not meet your bar?
- djur 9y ago
  Looks like VS Code is about 332 thousand lines of code. Facebook and Google's codebases are measured in the tens of millions of lines of code.
  - vvanders 9y ago
    A 10 million line javascript file must take a heck of a long time to load in the browser :).
    - yawaramin 9y ago
      Modern JavaScript is developed in separate modules (i.e. files).
      - mort96 9y ago
        Developed, yes, but in general, your build system bundles it all up into one javascript file which is sent to the browser. Even if you don't bundle the javascript, all the code has to be sent to the browser anyways, just over multiple HTTP requests instead of one.
        yawaramin 9y ago
        Right, but there can be many bundles for complex sites like Facebook. They can have a bundle for Messenger.com since it's a SPA, another for the FB home page, others for object pages, search pages, etc. etc....
        Can_Not 9y ago
        Except for small or basic apps, your build system is not suppose to build to only one file. It's suppose to build to a main file and separated module files. The module loader will pull in modules only when needed.
    - dmix 9y ago
      Google seems to be testing this theory with their adwords management web app :p
  - cwyers 9y ago
    Yes, but how often is it that you have to compile all of the TypeScript at one of those companies all at once? In practice, your build system should be able to shard compilation of all of the TS at something of that scale over many, many machines.
  - Matthias247 9y ago
    Alltogether? Maybe. But for a single library or webapp it will be hardly that much. I doubt that Facebook JS frontend code is much more than VS Code. I personally have only worked on up to medium sized projects (maybe 40000 LoC) in Typescript. I found compile times not to be a problem there, and I even though they were really on the good side of the spectrum. Didn't noticed any difference compared to similar sized C# or Java projects. All of those 3 have pretty neglible compile times compared against FB and Googles other main programming language: C++.
- shados 9y ago
  The relevent point IMO is the part about "10% perf improvement is a nice feature, a 10x one is invaluable". Essentially you have the svn branches vs git branch scenario here: svn branches were fast enough and people worked around the perf issues just fine with various strategies, bit git branches come in and change how branches are used altogether. So sure, you can just break down the project in a lot of libs or sub projects (that's what we do here: our app is broken down in hundreds of smaller ones so we never build the whole thing), but what if you didn't have to? Extreme case, in a magical land of fairies and unicorns: what if it was possible to git clone 100 million lines of code instantly, load them up in your editor (all of it) instantly, do all refactors/searches on the entire code instantly, live (without caches), and at every single keystroke rebuild everything, every time, with zero latency. How would that change your workflow and some architectural decisions? This is not a real question, but just something to think about, when we're talking about a compiler that could be 10x (or more) faster.
dmix 9y ago
I'm more curious to see how this compares to PureScript (http://www.purescript.org/ http://www.purescript.org/) rather than TypeScript. That seems more like a direct competitor in terms of bringing Haskell style algebraic data types into JS vs OCaml types / syntax in JS. Although the last time I used PureScript it was still very much in an immature alpha stage with frequent breaking changes with each new release. I'm excited to see what it grows into. Now I'll have to give BuckleScript a shot. PS: thanks for your hard work on this project :)
rattray 9y ago
Should project maturity be mentioned in the const of BuckleScript? (honest question) It's not clear to me what the volume of bugs, edge-cases, and likely future-backwards-incompatibilities are like.
evmar 9y ago
I work on TypeScript at Google, so just one point about scaling. Ultimately the only way to make things scale to large codebases is to make separate compilation work. That's what we do: separately compile separate pieces of the codebase. Even if A depends on B, we only recompile A if the API shape of B changes. Our incremental compilations while editing code are generally in <1s range, and our codebase is much larger than VSCode. I used to be a big fan/user of OCaml and though I haven't looked at BuckleScript in particular it sounds like a cool project. I think one con you overlook is that OCaml syntax/ecosystem is pretty hard on newcomers, though maybe Reason helps there. (And also my OCaml experience is years out of date so I'm sure it has improved since then.)
- jasim 9y ago
  I am a newcomer (started around 6 months ago), and it was not a smooth ride, but that was simply because of a lack of documentation. It has changed a lot since then - more people are writing about it, the Reason homepage itself has got a facelift with a bunch of new content, there are great error messages, there is always someone in the Discord channel to help you out, there are more and more bindings coming out every month, `ReasonReact` is seeing active improvement, and there is excellent IDE and tooling support. I can see a clear increase in momentum as more people join, and I think it'll only get better as the new syntax is released (which is very similar to Javascript than the typical space-delimited auto-curried FP syntax).
ihm 9y ago
Nice work! A few questions: can you speak to why one would choose BuckleScript over js_of_ocaml? Also, does BuckleScript support all of OCaml? Could you compile core_kernel using BuckleScript?
- yawaramin 9y ago
  You'd use BuckleScript to stay inside the npm ecosystem, and JSOO to stay in the opam ecosystem. Also BS if there's any chance that your output JS could be consumed by apps written in plain JS, or if you might one day want to move off of OCaml and back to plain JS. Re: core_kernel, I personally don't know, but it should be possible to the extent that it doesn't call out to C.

vvanders 9y ago

> Compiler slow (not scalable for FB/Google scale) I don't have any dog in this fight(I write Java/Native mostly) however I'd don't quite follow what you mean by FB/Google scale. I would consider VSCode a pretty complex piece of software and my understand is it written in TS. Have any concrete numbers you can share that makes it not meet your bar?

djur 9y ago
Looks like VS Code is about 332 thousand lines of code. Facebook and Google's codebases are measured in the tens of millions of lines of code.
- vvanders 9y ago
  A 10 million line javascript file must take a heck of a long time to load in the browser :).
  - yawaramin 9y ago
    Modern JavaScript is developed in separate modules (i.e. files).
    - mort96 9y ago
      Developed, yes, but in general, your build system bundles it all up into one javascript file which is sent to the browser. Even if you don't bundle the javascript, all the code has to be sent to the browser anyways, just over multiple HTTP requests instead of one.
      - yawaramin 9y ago
        Right, but there can be many bundles for complex sites like Facebook. They can have a bundle for Messenger.com since it's a SPA, another for the FB home page, others for object pages, search pages, etc. etc....
      - Can_Not 9y ago
        Except for small or basic apps, your build system is not suppose to build to only one file. It's suppose to build to a main file and separated module files. The module loader will pull in modules only when needed.
  - dmix 9y ago
    Google seems to be testing this theory with their adwords management web app :p
- cwyers 9y ago
  Yes, but how often is it that you have to compile all of the TypeScript at one of those companies all at once? In practice, your build system should be able to shard compilation of all of the TS at something of that scale over many, many machines.
- Matthias247 9y ago
  Alltogether? Maybe. But for a single library or webapp it will be hardly that much. I doubt that Facebook JS frontend code is much more than VS Code. I personally have only worked on up to medium sized projects (maybe 40000 LoC) in Typescript. I found compile times not to be a problem there, and I even though they were really on the good side of the spectrum. Didn't noticed any difference compared to similar sized C# or Java projects. All of those 3 have pretty neglible compile times compared against FB and Googles other main programming language: C++.
shados 9y ago
The relevent point IMO is the part about "10% perf improvement is a nice feature, a 10x one is invaluable". Essentially you have the svn branches vs git branch scenario here: svn branches were fast enough and people worked around the perf issues just fine with various strategies, bit git branches come in and change how branches are used altogether. So sure, you can just break down the project in a lot of libs or sub projects (that's what we do here: our app is broken down in hundreds of smaller ones so we never build the whole thing), but what if you didn't have to? Extreme case, in a magical land of fairies and unicorns: what if it was possible to git clone 100 million lines of code instantly, load them up in your editor (all of it) instantly, do all refactors/searches on the entire code instantly, live (without caches), and at every single keystroke rebuild everything, every time, with zero latency. How would that change your workflow and some architectural decisions? This is not a real question, but just something to think about, when we're talking about a compiler that could be 10x (or more) faster.

dmix 9y ago

I'm more curious to see how this compares to PureScript (http://www.purescript.org/ http://www.purescript.org/) rather than TypeScript. That seems more like a direct competitor in terms of bringing Haskell style algebraic data types into JS vs OCaml types / syntax in JS. Although the last time I used PureScript it was still very much in an immature alpha stage with frequent breaking changes with each new release. I'm excited to see what it grows into. Now I'll have to give BuckleScript a shot. PS: thanks for your hard work on this project :)

rattray 9y ago

Should project maturity be mentioned in the const of BuckleScript? (honest question) It's not clear to me what the volume of bugs, edge-cases, and likely future-backwards-incompatibilities are like.

evmar 9y ago

I work on TypeScript at Google, so just one point about scaling. Ultimately the only way to make things scale to large codebases is to make separate compilation work. That's what we do: separately compile separate pieces of the codebase. Even if A depends on B, we only recompile A if the API shape of B changes. Our incremental compilations while editing code are generally in <1s range, and our codebase is much larger than VSCode. I used to be a big fan/user of OCaml and though I haven't looked at BuckleScript in particular it sounds like a cool project. I think one con you overlook is that OCaml syntax/ecosystem is pretty hard on newcomers, though maybe Reason helps there. (And also my OCaml experience is years out of date so I'm sure it has improved since then.)

jasim 9y ago
I am a newcomer (started around 6 months ago), and it was not a smooth ride, but that was simply because of a lack of documentation. It has changed a lot since then - more people are writing about it, the Reason homepage itself has got a facelift with a bunch of new content, there are great error messages, there is always someone in the Discord channel to help you out, there are more and more bindings coming out every month, `ReasonReact` is seeing active improvement, and there is excellent IDE and tooling support. I can see a clear increase in momentum as more people join, and I think it'll only get better as the new syntax is released (which is very similar to Javascript than the typical space-delimited auto-curried FP syntax).

ihm 9y ago

Nice work! A few questions: can you speak to why one would choose BuckleScript over js_of_ocaml? Also, does BuckleScript support all of OCaml? Could you compile core_kernel using BuckleScript?

yawaramin 9y ago
You'd use BuckleScript to stay inside the npm ecosystem, and JSOO to stay in the opam ecosystem. Also BS if there's any chance that your output JS could be consumed by apps written in plain JS, or if you might one day want to move off of OCaml and back to plain JS. Re: core_kernel, I personally don't know, but it should be possible to the extent that it doesn't call out to C.