News for hackers. Stuff that matters.
Re:Google Feedback on TypeScript 3.5 by bsaul on Monday September 09, 2019 @07:04AM (#20917018)
A little off-topic:

I'm currently trying to find a way to write (type safe) business logic once, then reuse it pretty much everywhere (mobile / web / desktop),and it seems to me that typescript has become the only option. Javascript runtime is present everywhere, and can interface with anything.

Does someone knows of another alternative (viable right now, or in the coming months) ? I know llvm can theoretically target any platform, including wasm, but how painfull is it in practice ? Can you write a line of code that does a network request then expect it to run as it is on the browser and on mobile platforms ?

Re:Google Feedback on TypeScript 3.5 by rkangel on Monday September 09, 2019 @08:32AM (#20917487)
Dart is one option, and Flutter means that you can share UI code as well. Dart is a fundamentally boring language (in a good way). If you have any experience of OO langauges it will take about 10 minutes to pick up. I missed union types and pattern matching from FP, but otherwise it works well.
Re:Google Feedback on TypeScript 3.5 by GiorgioG on Monday September 09, 2019 @07:30AM (#20917142)
C# (with .NET Core 3.0 officially launching on the 23rd of September, Blazor (WASM) support is included.) I have been playing around with Blazor a bit with the preview releases and I have to say it's pretty slick.
Re:Google Feedback on TypeScript 3.5 by bsaul on Monday September 09, 2019 @10:18AM (#20918402)
Does JavascriptCore support running wasm (on ios and android) ?

Also, as i mentioned in another answer, i'm not only concerned about being able to run the code on another platform, but also having it run on an "friendly" environment (with some kind of cross-platform I/O api).

Re:Google Feedback on TypeScript 3.5 by stefano on Monday September 09, 2019 @07:50AM (#20917255)
Did they improve the download size?
Re:Google Feedback on TypeScript 3.5 by cutler on Monday September 09, 2019 @08:32AM (#20917491)
No and on that basis it's unusable. However that's because it downloads the whole runtime. Eventually MS intend to load only your compiled code.
Re:Google Feedback on TypeScript 3.5 by mattferderer on Monday September 09, 2019 @10:00AM (#20918218)
You can avoid that issue with the Server Side Blazor concept for business side portions of your application.

Depending on the application you can get extremely far with just using HTTP requests to an API for anything business logic related. A lot of apps over complicate themselves by trying to force a JS framework on the front end with no benefit to the user. I seem to prefer using non-SPAs these days over SPAs because very few places do them well. Google being a terrible SPA developer.

- Edit - I forgot to mention Elixir's Phoenix has LiveView which is similar to Server Side Blazor.

Re:Google Feedback on TypeScript 3.5 by cutler on Monday September 09, 2019 @08:12PM (#20923921)
As I understood Blazor as compiled business logic rather than a bundled runtime is due in a future release of .Net Core. Not sure if it's ready for 3.0 later this month but that will be the game-changer Blazor promises to be. Yes, Phoenix Live View is similar but unfortunately Elixir hasn't really captured sufficient mindshare for it to have an impact.
Re:Google Feedback on TypeScript 3.5 by ClumsyPilot on Tuesday September 10, 2019 @12:20PM (#20929878)
I would not be so categorical.

I have a data web-app heavy app where users will routinely view over 300MB of data in charts and photos. In this context, .net runtime is insignificant. In fact, you could could argue such data intensive applications should be native and use local storage. Lastly, the browser with cache .Net runtime, and won't download it very often.

Re:Google Feedback on TypeScript 3.5 by GordonS on Monday September 09, 2019 @08:10AM (#20917374)
Fable (https://fable.io) is perhaps another option - it compiles F# to JavaScript.
Re:Google Feedback on TypeScript 3.5 by wilgertvelinga on Monday September 09, 2019 @12:05PM (#20919407)
If you do go with TypeScript have a look at Nx. It's tooling around TypeScript monorepo that helps you do exactly what you want: write code once and share it between backend/multiple frontends. It suppports Express or NestJS in the backend and Angular, React, Web Components in the Frontend. https://nx.dev/

If you want to make it work with Ionic/NativeScript/Electron as well use xplat. https://github.com/nstudio/xplat

Re:Google Feedback on TypeScript 3.5 by bsaul on Monday September 09, 2019 @04:02PM (#20921850)
I don’t see anything regarding mobile platform (native).
Re:Google Feedback on TypeScript 3.5 by wilgertvelinga on Monday September 16, 2019 @05:09AM (#20982267)
True, it's not possible because you need to write your code in Swift / Objective-C for iOS and Kotlin / Java for Android. And Nx only supports TypeScript.
Re:Google Feedback on TypeScript 3.5 by cptwunderlich on Monday September 09, 2019 @07:39AM (#20917180)
I have no personal experience with this, but can't Kotlin target the JVM, native and JavaScript?
Re:Google Feedback on TypeScript 3.5 by softawre on Monday September 09, 2019 @03:47PM (#20921700)
Yeah. We've tried this, also sharing typescript code, but we've decided that sharing the same business logic code everywhere just isn't worth all the extra work to do so.
Re:Google Feedback on TypeScript 3.5 by rkangel on Monday September 09, 2019 @08:29AM (#20917474)
Have you looked at ReasonML/OCaml? It certainly compiles well for web (bucklescript) and desktop. I haven't tried it for mobile but I would be surprised if it didn't work well.

The ReasonML native tooling (i.e. non-web) is evolving, but it's fundamentally sugar on top of a long solid history of OCaml.

Re:Google Feedback on TypeScript 3.5 by bsaul on Monday September 09, 2019 @09:55AM (#20918174)
I'd love to have ML expressiveness. The only thing i'm a bit worried about is the I/O abstraction level.

I'm not really looking for a GUI abstraction layer, but i'd like to be able to write to a file, or perform a network request, in a platform-independant way. I'm afraid this requires a little bit more than just a javascript transpiler target.

Re:Google Feedback on TypeScript 3.5 by martinbooth on Tuesday September 10, 2019 @04:31AM (#20926173)
Reasonml is just an alternative syntax for ocaml so you can definitely use it for IO.

It's bucklescript that is an alternative backend for the ocaml compiler which allows you to output js, but you don't need to use it

Re:Google Feedback on TypeScript 3.5 by bsaul on Tuesday September 10, 2019 @09:39AM (#20928017)
That's where my understanding of compiler / Operating system / standard library falls a bit short.

I suppose the full ocaml standard library isn't available when you compile your code to native iOS or native Android, is it ?

I mean, iOS and and Android are probably not POSX compliant. File system and networking access have very specific constraints, that are way different than your regular server. At least that my feeling whenever i code in iOS. Your application needs to whitelist URLs in a plist, you need to work with foreground / background states (eg timer are paused when in background). I can't imagine that the standard ocaml library doesn't need adaptation to run in those environment.

Am i wrong ?

Re:Google Feedback on TypeScript 3.5 by slifin on Monday September 09, 2019 @07:49AM (#20917241)
Clojure has a specification language that can express more and less things than a type system can and runs on mobile web desktop with flexible choices for run times
Re:Google Feedback on TypeScript 3.5 by cutler on Monday September 09, 2019 @08:43AM (#20917559)
Good luck untangling re-native built on re-frame built on Reagent built on shadow-cljs built on React native built on React built on Android/iOS when one of those parts change.
Re:Google Feedback on TypeScript 3.5 by didibus on Monday September 09, 2019 @12:38PM (#20919730)
You make it sound like more of a tower than it actually is. It's just ClojureScript to React Native. All the others are simple frameworks and build tool to help you scaffold.
Re:Google Feedback on TypeScript 3.5 by dominotw on Monday September 09, 2019 @11:44AM (#20919199)
so in that equation applies to all of JS transpilers. Why this a clojurescript specific complaint?
Re:Google Feedback on TypeScript 3.5 by cutler on Monday September 09, 2019 @08:08PM (#20923894)
Because Clojurescript adds at least another 3 layers of indirection.
Re:Google Feedback on TypeScript 3.5 by Scarbutt on Monday September 09, 2019 @12:12PM (#20919472)
that can express more and less things

So which is it? ;)

Re:Google Feedback on TypeScript 3.5 by didibus on Monday September 09, 2019 @12:41PM (#20919751)
Not OP, but I'm guessing they meant it can express more, but it can statically type check less. Since Clojure's system is a runtime contract and not a static type checker.
Re:Google Feedback on TypeScript 3.5 by _bxg1 on Monday September 09, 2019 @01:08PM (#20920004)
I'm pretty sure most languages at this point can be made to run across all platforms, including mobile. The bigger question is how gross your tooling/interop is going to have to be to make all of that work, and how much your productivity will be thereby affected.