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.

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.

> 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/

> 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/) has types for over 3500 popular libraries: 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?la...

> I believe any language that supports "any" allows this. Doesn't Kotlin? 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-g....

Actually, the Kotlin equivalent to TS' any is 'dynamic': https://kotlinlang.org/docs/tutorials/javascript/working-wit...

You can declare a `dynamic` Kotlin variable like this:

   val myObject: dynamic = null

The myObject above is not type-safe. It seems that the reason for its existence is interop with existing JavaScript code.

The Kotlin `Any` class is actaully more related to Java's `Object` class. (It's the superclass of every Kotlin class.)

Yes, this is the effective difference between Typescript and typecasting in most other languages. Typescript, since it compiled to js, doesn't know the runtime type so it can't use reflection to make sure casts are valid. It just takes your word for it. If the cast isn't always correct prepare for a world of pain trying to track it down instead of getting an exception on casting failure

I encountered this the other day, while playing with typescript for the first time. Is there a good solution, such as a utility function that does a runtime check before casting? I suppose I could write one for each type cast, but it seems like I shouldn't need to.

Yes, a runtime check in TypeScript is the same as a runtime check in JavaScript.

    function inc(n) {
      if (typeof n === 'number') { return n + 1 }
      throw new Error('Parameter n is not a number');
    }

If you wanted to actually runtime check all types (probably not advised) you could parse the type annotations.

Or you could define your types using something like JSON Schema and validate against that.

https://github.com/bcherny/json-schema-to-typescript

https://github.com/YousefED/typescript-json-schema

I'm sorry to say but... This check won't help with accidental incorrect casts. Typeof in typescript is a pass through for the JavaScript function, so it only returns what the JS version does.

A check for a string or number will work, but a check against a typescript object or something complex like a union type will just return 'Object'

You can use a tslint rule to block casts. That way you will only be able to use type guards to change the type of something.

Kind of maybe. See http://blog.wolksoftware.com/decorators-reflection-javascrip... for use of experimental reflection API.

Note that Typescript tries to follow JS to remain a superset that easily compiles down, and the metadata API is currently a stage II Ecma proposal so it's marked experimental.

It should be fairly easy to build a types casting method using that.

> 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).

If you want top-type like behavior in TS, you want to use `{}` instead of any, since the language is structural. Anything satisfies it, but it exposes no members without a cast or guard to a more specific type.

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.

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.

No, Swift requires "any as? Cast" which returns "Optional<Cast>" (or you can use "any as! Cast" which at least crashes instead of happily proceeding with the wrong type).

Your critique is about JavaScript, not about TypeScript.

Your argument is that TS blindly trusts 3rd party typings, but Kotlin has the same exact issue! In fact the Kotlin docs say to use TypeScript typings, or "dynamic" (read: unsafe) mode for 3rd party libs. So I would expect the same level of safety between TS and Kotlin when it comes to 3rd party libs.

I personally prefer TS because it's safer: with literal types and mapped types, my code is far safer than the equivalent Kotlin. It will surprise you how often you use these features.

To add to that, TypeScript is a superset of JavaScript, whereas Kotlin is a new language you'd have to learn.

> Since Java has always been strongly typed and has a ton of libraries available

Means nothing for alt-Java languages' JS target. While the host language gets the Java ecosystem for free, to replicate on the client every Java library needs to be cross compiled.

It's a non-trivial endeavor, one that ClojureScript and Scala.Js can largely avoid due to their already having a rich set of cross compiled frameworks and libraries in their respective ecosystems.

Not sure what the story is with Kotlin here, seems pretty tightly coupled to Java.

The Java classpath (built in API) will be an issue possibly. It's easy to compile third party libraries statically with your app. Just build a fatjar with maven shade and strip it with progaurd. You application will be only the Java runtime and code you're actually calling.

I've tested this with Java console apps and it makes them very small. I'm guessing you could get your app size under 50kb

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?

I second Clojurescript. Peter Hunt, the creator or React, was heavily influenced by Clojurescript and David Nolen.

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

Rich Hickey is one of the rare breed of thinkers in the programming world whose ideas have great relevance even if you're not interested in the language he invented.

Any good tutorial for Kotlin as a JS replacement? I am one of those people hating JS (and I did some very advanced JS web apps pushing technological possibilities) and would love to have something sane before WebAssembly can completely obliterate JS and I can switch to whatever language I like. Thanks for any hints!

> before WebAssembly can completely obliterate JS and I can switch to whatever language I like.

This is exactly what I'm waiting for.

I never tried Kotlin, but I'm working with Scala.js since 1.5 years and am very happy with it: http://www.scala-js.org This made me love the frontend again.

I'd really like this too, especially to see what it looks like in a react native world.

Being able to compile to 2/3 platforms would be a huge plus

>10.000%

To clarify, you mean 10000%, right? My American brain really wants to parse that as a (very precise) 10% improvement.

No, he means 10.000 which in parts of Europe is the same is 10,000 in the US. 10000 is the same thing as both. What's strange to me is that you seem to know this but still want to say something about it.

Its like an Englishman saying colour and you saying, "you mean color, right?" Just seems unnecessary.

>What's strange to me is that you seem to know this but still want to say something about it.

Because on a world-wide message board it's still inherently ambiguous. My comment was meant to serve two purposes. First, to draw attention to the ambiguity for others who use `.` as a decimal separator and read "10.000" as "10" (as I very nearly did). Second, to seek clarification because there is a non-zero chance that the OP is in fact a precision-minded person who saw a small productivity improvement when switching to Kotlin.

>Its like an Englishman saying colour and you saying, "you mean color, right?" Just seems unnecessary.

More like when an Englishman says "biscuit". in many contexts I would ask for clarification because my definition of "biscuit" is different from the common British usage, but it's also possible that the Englishman knows this and really does mean "American biscuit".

As an American who moved to the UK, I second your defence.

Awareness that you might be misinterpreting something and seeking to get clarity is a virtuous habit, both in programming and in productive discourse.

As an Englishman who still doesn't quite understand what an American biscuit is or why on earth you would put gravy on it, I second your defence too. It was a perfectly polite clarification.

If you've not actually experienced them in person, it might help to think of them as small savory (not sweet) cakes, typically served hot. Generally salty and fairly high in fat. They serve much the same role as croissant, but from an area where much of the flour was "pastry" flour which lacks the structure and tensile strength for yeast - raised bread.

An American biscuit is actually a Scottish scone. (Note, not what most people in the US or England know as a scone but a specific item historically made in Scotland that is identical to the US biscuit).

Source: my grandfather made them.

As to gravy: yes. Odd.

FWIW, I read it as 10% and would not have had it fixed if not for your comment.

I also felt spending an hour for a 10% productivity boost was well worth it, so it didn't strike me as odd.

A 9.999% boost wouldn't be worth it though, so I appreciated the extra precision.

Sorry I didn't respond very timely, but after considering the comment chain, I think perhaps you are right. The irony, now, is my comment was the unnecessary one.

I think you're reading into it wrong. 0xffff2 isn't correcting the parent, rather trying to clarify that by saying 10.000, that would be equivalent to 10000, since in America we use commas instead of periods for thousands denotation. We can't automatically know where people live and what standards they use, so we ask to clarify.

It's not a matter of geography. It's a matter of language. In English, a period acts as the radix point and a comma acts as a separator. It's a common error for people who learned English as a second language to use the convention of their native language when writing in English.

No, it's a matter of geography (or should I say locale). Raised in South Africa, we English speakers were taught to write "ten thousand and forty one-hundredths" as

    10.000,40

which is exactly the opposite of the US based

    10,000.40

So it's locale rather than language that determines this.

> source = "date"

> source = "produktname"

Honestly that doesn't look "completely typesafe": what are those "source"s? Don't they refer to another element? What happens if you make a typo there?

I wager there is type inference going on and that the IDE will supply red squiggly lines beneath the expression if the author were to supply something that would not one way or the other convert to the types that source can consume.

> I wager there is type inference going on

What will the compiler infer other than a value of type string?

> to supply something that would not one way or the other convert to the types that source can consume.

Well, clearly `source` takes a string, so it will happily accept "produckname" and blow up at run time.

Short of macros I know of no other compile time mechanism that would enable "safe" strings. The usual workaround is to not use plain string values at all and wrap in a sealed type.

It maps to database fields. The compiler checks that it's a string, but the rest is done by `admin-on-rest`'s mapping.

This is from the JS-library "admin-on-rest", that I use (via bindings). It's possible to introduce type-safe wrappers here as well.

I did the same thing when implementing [TodoMVC](http://todomvc.com/). You can check out the results [here](https://github.com/AppCraft-Projects/todomvc-kotlin). I will never write javascript again if I can help it.

Is the Kotlin version example available to run off the site? Poked around for a while but can't see it..

No, I did not submit it yet (may never will). It was created for a talk at Kotlin Budapest Meetup.

Thanks. I loaded it in Idea. Just need to figure out how to run it now...

Hey this sounds like a great setup. I've been wondering if Kotlin -> JavaScript could work for React. Do you have some more documentation or code that you could share on how to setup a project?

Given that this was merely a week ago and you had to write your own bindings, I'd wait a bit with your evaluation to see whether other annoyances come up. That productivity boost is not likely to remain that high :)

I saw the light last week as well. You can combine this with Quasar to get Erlang style concurrency. I wonder if you can somehow hook up, idk RxJS on the client with RxJava on the server for seamless integration.

The JSON story is also amazing.

This stack is gonna be the biggest deal in the world.

Not to mention that you can run it on Android and soon enough iOS. This is unprecedented.

Sorry, I firmly believe that nothing gets Erlang-style concurrency except Erlang. Other ecosystems may get something that mimics Erlang's concurrency, but the imitation is skin-deep.

I know, I played around with quasar a couple of month ago.

> Writing the react-bindings took me an hour,...

Do you mean generic 'use react in kotlin' bindings? If so, have you published them or would you consider doing so?

Yes.

I have not published them, because

a) they use the same method names like the `kotlin-html` package ("div{}" et. al.), only they create ReactElement instead of manipulating the dom. This could be confusing.

b) The type-safe scoping mechanism, so that each scope has it's correct prop-setters and won't inherit setters from a scope further up is rather complex. It uses extension methods with multiple receivers plus operator overrides for `invoke()`.

That is rather complicated to follow so I want to try it out for some time to check if there's confusion or subtle bugs.

c) I haven't optimised for (allocation-)performance yet.

d) I'm using an early-access version of kotlin 1.1.4 which isn't out yet.

Here is a good tutorial if you'd like to try it yourself:

https://kotlinlang.org/docs/reference/type-safe-builders.htm...

Did you follow a framework or roll your own? I'm thoroughly fascinated with isomorphic kotlin, but haven't had a chance to dig in yet.

With kotlin I seldom need a framework, because the standard-library is so rich.

In general, when I tend to follow a data-flow ("redux" for JS people) architecture, but have a different approach when it comes to side-effects: My state is always a serialisable description including running side-effects. So even network-requests can be reconstructed from a state-file.

Also I decouple View/React from the actual state via interfaces.

Meaning my state doesn't necessarily contain the data in the format my Views need, but it's able to supply the data via delegation.

If I need background-threads I use actors / CSP.

This sounds really interesting, do you have any examples or a blog post explaining this in more detail?

No, but I'll might write it up at some point.

So much to do, so little time ;)

Curious what the output of this is(photo), it looks like it would create something with the div/textfields? Is it an inline span element that is editable but not an actual <input type> ?

I'm behind on frameworks, I just build with html/css/js/php

Well, if I had to pick a single recommendation for improvement of any web-development-cycle, it would be `Tachyons.css`:

http://tachyons.io/

There are a few concepts that I don't personally use but see on a page I can literally build anything drawn on a piece of paper (for web) but the question is how long will I take?

Also the security aspect and whatever with regard to using Laravel vs. using your own PHP.

I don't know I'll figure it out.

Thanks for the link to tachyons.css

More tips: * Never use object-relational mapping * Use postgreSQL instead of mySQL * (optionally) switch from PHP to python

Hi, would you mind telling which IDE you are using? This sounds very interesting.

While you can do Kotlin development in Eclipse (and others), IntelliJ is basically _the_ IDE for Kotlin, since they are both developed by the same company (JetBrains).

IntelliJ IDEA, Community Edition.

Java? why?

Because it's probably the most-advance virtual machine out there. It has a massive ecosystem, many years of testing and battle-tested devops-tooling. It has everything.

which do you like more React Native or NativeScript(Angular)

Never used Angular nor NativeScript.

I get along with ReactNative, it's decent. The data-application part of my last android-app was already written in (JVM-)Kotlin and in the futures the UI will be as well. ;)

I recommend my styling library for React-native: https://github.com/tachyons-css/react-native-style-tachyons