5 ms·

What advantages does this have over Typescript? The ecosystem and mindshare are overwhelmingly in TS' favor I would imagine. For compile-to-js languages it see

What advantages does this have over Typescript? The ecosystem and mindshare are overwhelmingly in TS' favor I would imagine. For compile-to-js languages it seems most attractive to those that use the host language (Clojure, Scala, Kotlin, Haskell, etc.), whereas for would be js expats, Typescript seems like the natural choice given current trends. I think for a compile-to-js language (vs. a transpiler like Typescript) to take off it's going to need at least: Tiny generated binaries Great js interop Large ecosystem Seamless cross compilation (e.g. JVM/JS) Fast compiler Reason + Bucklescript is the only combination I know of that could potentially pull off the above, blazing fast compilation and miniscule binaries being its greatest strengths at the moment.

slackingoff2017 9y ago
Typescript still has some issues that only a "real" strongly typed language can fix. The biggest one is related to third party JS/TS libraries. If the object was 'any' at some point, if you make an invalid cast Typescript will trust you. If it's a union type, typically (Obj | undefined), everything will work fine until one day the object is undefined and everything blows up. You won't know because everywhere in your code the object can never be undefined. Essentially Typescript Is too trusting. In Java or similar languages, if something comes in as Object you know all bets are off. If you cast and it succeeds you know 100% what kind of object it is. In Typescript it's possible for the type to look fine but be completely wrong, or worse, wrong in a subtle way. And there's no way to fix this without breaking interop with JavaScript. Since Java has always been strongly typed and has a ton of libraries available this isn't an issue in Kotlin. Java/Kotlin are just far better designed languages and no amount of banging on JS is going to make it as well designed. Look at PHP, after 10+ years of trying to make it reasonable it's only "okay", there's too much baggage. The bytecode for Java/C# is much more compact than JS, the runtime is about 10x faster, they have far better standard libraries. They will compile down easily to wasm since their VM's essentially already compile down to native machine code on whatever platform they run on. It's as easy as adding a "wasm" machine target to their runtime and porting the garbage collectors. I fully expect Wasm to wipe out front end development as we know it. Java and C# are far better suited for what the web has become, essentially an application platform. We've seen the future already, just 10 years too early, in Java applets.
- spion 9y ago
  > If the object was 'any' at some point, if you make an invalid cast Typescript will trust you. I believe any language that supports "any" allows this. Doesn't Kotlin? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ > If it's a union type, typically (Obj | undefined), everything will work fine until one day the object is undefined and everything blows up. Not if you set strict: true in your typescript options, or you can separately enable just strictNullChecks > Essentially Typescript Is too trusting. In Java or similar languages, if something comes in as Object you know all bets are off. If you cast and it succeeds you know 100% what kind of object it is. In Typescript it's possible for the type to look fine but be completely wrong, or worse, wrong in a subtle way. And there's no way to fix this without breaking interop with JavaScript. Instead of casts that fail, typically you would use type guards to deal with this. That way you can isolate unsafe casting code to a single place. > Since Java has always been strongly typed and has a ton of libraries available this isn't an issue in Kotlin. DefinitelyTyped (http://definitelytyped.org/ http://definitelytyped.org/) has types for over 3500 popular libraries: https://www.npmjs.com/~types https://www.npmjs.com/~types > the runtime is about 10x faster. Hmm. I see 1.5x-6x here, with average around 3-4x: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=java https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
  - bpicolo 9y ago
    Fwiw, microbenchmarks are not a good indicator of application perf in general. That said, nodejs is pretty fast. Also a memory hog, and doesn't support parallelization.
    - slackingoff2017 9y ago
      I always have a chuckle when JS fanatics talk about Java's "huge runtime" when Node and webapps use stupid amounts of ram. Java's memory efficiency is stellar in comparison.
  - Nullabillity 9y ago
    > I believe any language that supports "any" allows this. Doesn't Kotlin? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ Kotlin's Any is pretty much the opposite of TypeScript's any. In TS it disables type checking completely (according to the docs). In Kotlin it's the top type (similar to Java's Object type), which anything conforms with, but doesn't expose any operations at all (except for the stuff that the JVM provides for free). The closest match to TS' any would probably be C#'s dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-g....
lopatin 9y ago
I think that ClojureScript fits this criteria as well. 1. The resulting file size is great, heavily optimized and tree-shaked with Goog Closure Compiler. It seems Bucklescript does even better in this regard! 2. It's there, easy to use, does what you expect. A++ would interop again. 3. The ClojureScript community has some of the best libraries for web development such as DataScript, Specter, Reagent, Re-frame, Om, Rum, etc... Not to mention all the other cool built in stuff. core.async, core.logic, core.spec have been invaluable to me. 4. In my experience, you can re-use most of your core Clojure code in CloureScript. Just put them in a .cljc file. There are platform specific APIs as well, and those will be specific to your platform of course. The only annoying thing is that you have to define your macros in a different file as your .cljs if I recall correctly. 5. The compiler is fast, but to be honest it doesn't even matter because of the state of the art tooling and browser integration you get during development, you don't have to recompile the project after saving a file. If you think Webpack has nice reloading features and dev tools integration, wait until you connect to the browser via a Clojure REPL directly from your IDE (or terminal). It's just bliss. So here's my take. From a *-to-js language infrastructure point of view, we already have multiple good choices. However, from a language design/culture perspective, both of these languages are esoteric and most likely always will be. They won't catch on, like TypeScript might. Lisp isn't new. ML isn't either. There's a reason they haven't taken over Java on the server side of things for example. For the foreseeable future, these languages exist just for the minority of programmers who have decided they want something better. You can have both, so the question is, what's your poison? LISP or ML?
- cutler 9y ago
  I second Clojurescript. Peter Hunt, the creator or React, was heavily influenced by Clojurescript and David Nolen.
  - lopatin 9y ago
    I think he goes by Pete ;) Edit: While I'm here, might as well link to the Simple Made Easy talk by Rich Hickey. The other thing (aside from inventing Clojure) that gave him prophet-like status in the community. https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy

slackingoff2017 9y ago

Typescript still has some issues that only a "real" strongly typed language can fix. The biggest one is related to third party JS/TS libraries. If the object was 'any' at some point, if you make an invalid cast Typescript will trust you. If it's a union type, typically (Obj | undefined), everything will work fine until one day the object is undefined and everything blows up. You won't know because everywhere in your code the object can never be undefined. Essentially Typescript Is too trusting. In Java or similar languages, if something comes in as Object you know all bets are off. If you cast and it succeeds you know 100% what kind of object it is. In Typescript it's possible for the type to look fine but be completely wrong, or worse, wrong in a subtle way. And there's no way to fix this without breaking interop with JavaScript. Since Java has always been strongly typed and has a ton of libraries available this isn't an issue in Kotlin. Java/Kotlin are just far better designed languages and no amount of banging on JS is going to make it as well designed. Look at PHP, after 10+ years of trying to make it reasonable it's only "okay", there's too much baggage. The bytecode for Java/C# is much more compact than JS, the runtime is about 10x faster, they have far better standard libraries. They will compile down easily to wasm since their VM's essentially already compile down to native machine code on whatever platform they run on. It's as easy as adding a "wasm" machine target to their runtime and porting the garbage collectors. I fully expect Wasm to wipe out front end development as we know it. Java and C# are far better suited for what the web has become, essentially an application platform. We've seen the future already, just 10 years too early, in Java applets.

spion 9y ago
> If the object was 'any' at some point, if you make an invalid cast Typescript will trust you. I believe any language that supports "any" allows this. Doesn't Kotlin? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ > If it's a union type, typically (Obj | undefined), everything will work fine until one day the object is undefined and everything blows up. Not if you set strict: true in your typescript options, or you can separately enable just strictNullChecks > Essentially Typescript Is too trusting. In Java or similar languages, if something comes in as Object you know all bets are off. If you cast and it succeeds you know 100% what kind of object it is. In Typescript it's possible for the type to look fine but be completely wrong, or worse, wrong in a subtle way. And there's no way to fix this without breaking interop with JavaScript. Instead of casts that fail, typically you would use type guards to deal with this. That way you can isolate unsafe casting code to a single place. > Since Java has always been strongly typed and has a ton of libraries available this isn't an issue in Kotlin. DefinitelyTyped (http://definitelytyped.org/ http://definitelytyped.org/) has types for over 3500 popular libraries: https://www.npmjs.com/~types https://www.npmjs.com/~types > the runtime is about 10x faster. Hmm. I see 1.5x-6x here, with average around 3-4x: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=java https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
- bpicolo 9y ago
  Fwiw, microbenchmarks are not a good indicator of application perf in general. That said, nodejs is pretty fast. Also a memory hog, and doesn't support parallelization.
  - slackingoff2017 9y ago
    I always have a chuckle when JS fanatics talk about Java's "huge runtime" when Node and webapps use stupid amounts of ram. Java's memory efficiency is stellar in comparison.
- Nullabillity 9y ago
  > I believe any language that supports "any" allows this. Doesn't Kotlin? https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/ Kotlin's Any is pretty much the opposite of TypeScript's any. In TS it disables type checking completely (according to the docs). In Kotlin it's the top type (similar to Java's Object type), which anything conforms with, but doesn't expose any operations at all (except for the stuff that the JVM provides for free). The closest match to TS' any would probably be C#'s dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-g....

lopatin 9y ago

I think that ClojureScript fits this criteria as well. 1. The resulting file size is great, heavily optimized and tree-shaked with Goog Closure Compiler. It seems Bucklescript does even better in this regard! 2. It's there, easy to use, does what you expect. A++ would interop again. 3. The ClojureScript community has some of the best libraries for web development such as DataScript, Specter, Reagent, Re-frame, Om, Rum, etc... Not to mention all the other cool built in stuff. core.async, core.logic, core.spec have been invaluable to me. 4. In my experience, you can re-use most of your core Clojure code in CloureScript. Just put them in a .cljc file. There are platform specific APIs as well, and those will be specific to your platform of course. The only annoying thing is that you have to define your macros in a different file as your .cljs if I recall correctly. 5. The compiler is fast, but to be honest it doesn't even matter because of the state of the art tooling and browser integration you get during development, you don't have to recompile the project after saving a file. If you think Webpack has nice reloading features and dev tools integration, wait until you connect to the browser via a Clojure REPL directly from your IDE (or terminal). It's just bliss. So here's my take. From a *-to-js language infrastructure point of view, we already have multiple good choices. However, from a language design/culture perspective, both of these languages are esoteric and most likely always will be. They won't catch on, like TypeScript might. Lisp isn't new. ML isn't either. There's a reason they haven't taken over Java on the server side of things for example. For the foreseeable future, these languages exist just for the minority of programmers who have decided they want something better. You can have both, so the question is, what's your poison? LISP or ML?

cutler 9y ago
I second Clojurescript. Peter Hunt, the creator or React, was heavily influenced by Clojurescript and David Nolen.
- lopatin 9y ago
  I think he goes by Pete ;) Edit: While I'm here, might as well link to the Simple Made Easy talk by Rich Hickey. The other thing (aside from inventing Clojure) that gave him prophet-like status in the community. https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy