6 ms·

Using kotlin in web pages, client side and server side could be a big win. You could be able to use exactly the same language in all you stack. Although program

by jorgemf 10y ago

Using kotlin in web pages, client side and server side could be a big win. You could be able to use exactly the same language in all you stack. Although programming for the frontend will be different than programming for the backend, the fact that any of them can review the code of the others is great. You could also move resources in peak times to help a little.

realharo 10y ago
I still prefer TypeScript for web frontend code, because it fits a lot nicer into that ecosystem (React, MobX, webpack, etc.) and the structural typing also feels better suited for that environement. Kotlin could however be awesome for cross-platform mobile dev, targeting both iOS and Android with a lot of shared code and truly native apps on both.
- jorgemf 10y ago
  TypeSript is more mature and better option for frontEnd now, but I hope kotlin will catch up. I wouldn't use kotlin for cross-platform mobile dev. There are few things Android and iOS share, you end up having to codebases in the same language (which it is good in its way). If you want to do truly native apps, just avoid sharing code because you will use different patterns and different libraries and apis. You could share the business logic but that is something I think should be on the server not in the app. The app is only the frontend.
  - realharo 10y ago
    In my experience, there is a lot of opportunity for sharing code between mobile platforms that doesn't have any real downsides. Things like: - data structures for your domain objects - network code (just plug in an appropriate platform-specific driver) - like you said, business logic - especially if the app has to work offline - if you're using something like https://realm.io/ https://realm.io/, you could avoid a lot of duplication Anything to do with the UI then has to be platform-specific of course.
    - jorgemf 10y ago
      > - data structures for your domain objects not sure there are a problem since you have data classes in kotlin. I bet swift provides something similar. > - network code In Android you must use okhttp, and I guess there are similar powerful libraries in swift for this. > - if you're using something like https://realm.io/ https://realm.io/ Last time I checked it I decided to keep using SQLite as it allows me to do everything I want. Realm doesn't support "complex" SQL queries. Again, just business logic. But there is no too much apart from field validation or simplex operations to show the data (or it should be much more). Complex things must be in the server, that is the best way to share business logic among all your apps in all the platforms.
      - relics443 10y ago
        For anyone not that familiar with Android, "must use okhttp" refers to the fact that it is the best solution, not that it's the only solution.
superzadeh 10y ago
> use exactly the same language in all you stack isn't this what people are doing with JavaScript?
- mathw 10y ago
  It is, but the problem with that is that they're doing it in JavaScript. Kotlin could offer better performance and certainly offers strong type safety throughout the stack, which I at least certainly believe gives a better programming experience.
  - hasenj 10y ago
    Have you tried TypeScript?
    - deno 10y ago
      Typescript is nice but its type system is not the strongest selling point. For example this compiles without warnings: const foo: Promise<string|null> = Promise.resolve(null); const bar: Promise<string> = foo; bar.then((value) => value.toString()); // runtime null error
      - coldtea 10y ago
        That's because null is an acceptable value for a string object. Which is the same thing as in Java and plenty of other languages.
        deleted 10y ago
        [deleted]
        ptx 10y ago
        Not in Kotlin, though. You have to make it explicitly nullable if you want it to be null.
        10y ago

by jorgemf 10y ago

realharo 10y ago

I still prefer TypeScript for web frontend code, because it fits a lot nicer into that ecosystem (React, MobX, webpack, etc.) and the structural typing also feels better suited for that environement. Kotlin could however be awesome for cross-platform mobile dev, targeting both iOS and Android with a lot of shared code and truly native apps on both.

jorgemf 10y ago
TypeSript is more mature and better option for frontEnd now, but I hope kotlin will catch up. I wouldn't use kotlin for cross-platform mobile dev. There are few things Android and iOS share, you end up having to codebases in the same language (which it is good in its way). If you want to do truly native apps, just avoid sharing code because you will use different patterns and different libraries and apis. You could share the business logic but that is something I think should be on the server not in the app. The app is only the frontend.
- realharo 10y ago
  In my experience, there is a lot of opportunity for sharing code between mobile platforms that doesn't have any real downsides. Things like: - data structures for your domain objects - network code (just plug in an appropriate platform-specific driver) - like you said, business logic - especially if the app has to work offline - if you're using something like https://realm.io/ https://realm.io/, you could avoid a lot of duplication Anything to do with the UI then has to be platform-specific of course.
  - jorgemf 10y ago
    > - data structures for your domain objects not sure there are a problem since you have data classes in kotlin. I bet swift provides something similar. > - network code In Android you must use okhttp, and I guess there are similar powerful libraries in swift for this. > - if you're using something like https://realm.io/ https://realm.io/ Last time I checked it I decided to keep using SQLite as it allows me to do everything I want. Realm doesn't support "complex" SQL queries. Again, just business logic. But there is no too much apart from field validation or simplex operations to show the data (or it should be much more). Complex things must be in the server, that is the best way to share business logic among all your apps in all the platforms.
    - relics443 10y ago
      For anyone not that familiar with Android, "must use okhttp" refers to the fact that it is the best solution, not that it's the only solution.

superzadeh 10y ago

> use exactly the same language in all you stack isn't this what people are doing with JavaScript?

mathw 10y ago
It is, but the problem with that is that they're doing it in JavaScript. Kotlin could offer better performance and certainly offers strong type safety throughout the stack, which I at least certainly believe gives a better programming experience.
- hasenj 10y ago
  Have you tried TypeScript?
  - deno 10y ago
    Typescript is nice but its type system is not the strongest selling point. For example this compiles without warnings: const foo: Promise<string|null> = Promise.resolve(null); const bar: Promise<string> = foo; bar.then((value) => value.toString()); // runtime null error
    - coldtea 10y ago
      That's because null is an acceptable value for a string object. Which is the same thing as in Java and plenty of other languages.
      - deleted 10y ago
        [deleted]
      - ptx 10y ago
        Not in Kotlin, though. You have to make it explicitly nullable if you want it to be null.
        10y ago