4 ms·

I happily made the switch from Obj-C to Swift when it was announced, partly because Apple said they wanted to make it a true cross platform language. So far th

I happily made the switch from Obj-C to Swift when it was announced, partly because Apple said they wanted to make it a true cross platform language. So far that doesn't seem to have really happened and in the meantime I've switched to Typescript and more recently Dart (for Flutter), which currently both have much better cross platform stories.

auggierose 3y ago
Yes, exactly. Interoperable doesn't mean much if it is not properly cross platform. I've tried Dart for a project, and it worked OK, but in my opinion TypeScript is clearly the way to go in the foreseeable future.
- pjmlp 3y ago
  Typescript is limited by V8 capabilities, and the constraints of a dynamic language JIT. To achieve best perfomance one needs to write C++ code as native modules. Interoperable means a lot even inside Apple ecosystem, bringing all those C, Objective-C and now C++ code with ease into Swift projects. Using Metal from Swift, althought implemented in Objective-C and C++, is already a productivity boost compared to anything that Microsoft has ever produced for .NET in regards to DirectX, not even XNA.
  - auggierose 3y ago
    If you are on the Apple platform only, Swift is great, and I enjoyed using Metal myself. But eventually I accepted how much it limited what I can do as a developer. So, I prefer TypeScript now. I am not touching C++ or stuff like that, if I need performance, I compile to web assembly, hopefully soon from my own language :-)
    - pjmlp 3y ago
      Web Assembly and performance on the same sentene is an oxymoron.
      - auggierose 3y ago
        WebGPU + WebAssembly + TypeScript is going to be a pretty potent combo. I doubt Swift + Metal is more performant. Actually, when I translated some Swift code to JavaScript, it ran faster.
        pjmlp 3y ago
        WebGPU exposes 2015 hardware. If you failed to make Swift + Metal perform better than JavaScript, there is something really horrible with your code.
        auggierose 3y ago
        I'd say there are plenty of use cases where access to 2015 hardware capabilities is more than enough, given that you will profit from any automatic speed improvements beyond 2015 hardware as well. Which features beyond 2015 are you referring to? The code I ported wasn't Swift+Metal, it was just Swift. It certainly wasn't optimized in any way, but the Javascript one wasn't either. Javascript data structures are just faster, because they are fully imperative, the Swift ones are more expensive, despite some copy-on-write tricks. And remember, carefully written Javascript is just as fast as C.
        pjmlp 3y ago
        Mesh shaders, ray tracing, unified memory, direct IO,... V8 JIT is hardly as fast as C, almost there yeah, there is still a speed bump.
        auggierose 3y ago
        Yes, if you need these things, you will have to go native (although you will probably automatically benefit from unified memory). For many many things, you won't, and then the ability to target Apple/Windows/Linux with exactly the same code, pain-free GPU access etc, that's just great. The other day I checked if I can access from the browser the 3D coordinates of my space mouse, and it just works, based on a standard Web API (GamePad API). While from Swift, it would be a hassle to setup and maintain.
  - mst 3y ago
    I'd note that I've seen cases where the V8 JIT was sufficiently good that thunking to C++ and back meant that the performance difference was minimal. But that was for 'js library backed by C++' shaped cases whereas for performance critical app-specific code you probably want 'C++ library that presents a JS interface at the top level.'
- cageface 3y ago
  Typescript is a safe bet. I think for mobile apps Flutter is a better tech stack than React Native though and can survive if Google doesn’t give up on it.
  - joshgachnang 3y ago
    That last one is a big caveat and a major reason I'm not interested in Flutter.
  - Cthulhu_ 3y ago
    "if" exactly, Google has a tendency to drop projects out of nowhere, or to suddenly change course on it. Another big "no" factor with Flutter for me is that it's its own ecosystem and language; React Native ties in with the greater React ecosystem and the even greater Node ecosystem, which gives you a lot of libraries, code examples, maintenance and improvements. Second, hiring is a major factor. You can assign most current-day web developers onto a RN project with little problems, whereas Flutter is a new language and skill set.
    - cageface 3y ago
      Sure it’s a valid concern. I’m building my own app so hiring isn’t a concern for me. So far I’ve found the Flutter library ecosystem to be more than adequate for my needs and I’m finding it a far more pleasant and productive platform than React Native to work in. I always found RN very easy to get started with but over time as features get added and dependencies evolve RN apps become increasingly difficult to update and maintain. Also React is one of those easy to learn but difficult to master technologies. I’ve interviewed a lot of people claiming to know React that I wouldn’t trust to build anything complex. There are just so many footguns.

auggierose 3y ago

Yes, exactly. Interoperable doesn't mean much if it is not properly cross platform. I've tried Dart for a project, and it worked OK, but in my opinion TypeScript is clearly the way to go in the foreseeable future.

pjmlp 3y ago
Typescript is limited by V8 capabilities, and the constraints of a dynamic language JIT. To achieve best perfomance one needs to write C++ code as native modules. Interoperable means a lot even inside Apple ecosystem, bringing all those C, Objective-C and now C++ code with ease into Swift projects. Using Metal from Swift, althought implemented in Objective-C and C++, is already a productivity boost compared to anything that Microsoft has ever produced for .NET in regards to DirectX, not even XNA.
- auggierose 3y ago
  If you are on the Apple platform only, Swift is great, and I enjoyed using Metal myself. But eventually I accepted how much it limited what I can do as a developer. So, I prefer TypeScript now. I am not touching C++ or stuff like that, if I need performance, I compile to web assembly, hopefully soon from my own language :-)
  - pjmlp 3y ago
    Web Assembly and performance on the same sentene is an oxymoron.
    - auggierose 3y ago
      WebGPU + WebAssembly + TypeScript is going to be a pretty potent combo. I doubt Swift + Metal is more performant. Actually, when I translated some Swift code to JavaScript, it ran faster.
      - pjmlp 3y ago
        WebGPU exposes 2015 hardware. If you failed to make Swift + Metal perform better than JavaScript, there is something really horrible with your code.
        auggierose 3y ago
        I'd say there are plenty of use cases where access to 2015 hardware capabilities is more than enough, given that you will profit from any automatic speed improvements beyond 2015 hardware as well. Which features beyond 2015 are you referring to? The code I ported wasn't Swift+Metal, it was just Swift. It certainly wasn't optimized in any way, but the Javascript one wasn't either. Javascript data structures are just faster, because they are fully imperative, the Swift ones are more expensive, despite some copy-on-write tricks. And remember, carefully written Javascript is just as fast as C.
        pjmlp 3y ago
        Mesh shaders, ray tracing, unified memory, direct IO,... V8 JIT is hardly as fast as C, almost there yeah, there is still a speed bump.
        auggierose 3y ago
        Yes, if you need these things, you will have to go native (although you will probably automatically benefit from unified memory). For many many things, you won't, and then the ability to target Apple/Windows/Linux with exactly the same code, pain-free GPU access etc, that's just great. The other day I checked if I can access from the browser the 3D coordinates of my space mouse, and it just works, based on a standard Web API (GamePad API). While from Swift, it would be a hassle to setup and maintain.
- mst 3y ago
  I'd note that I've seen cases where the V8 JIT was sufficiently good that thunking to C++ and back meant that the performance difference was minimal. But that was for 'js library backed by C++' shaped cases whereas for performance critical app-specific code you probably want 'C++ library that presents a JS interface at the top level.'
cageface 3y ago
Typescript is a safe bet. I think for mobile apps Flutter is a better tech stack than React Native though and can survive if Google doesn’t give up on it.
- joshgachnang 3y ago
  That last one is a big caveat and a major reason I'm not interested in Flutter.
- Cthulhu_ 3y ago
  "if" exactly, Google has a tendency to drop projects out of nowhere, or to suddenly change course on it. Another big "no" factor with Flutter for me is that it's its own ecosystem and language; React Native ties in with the greater React ecosystem and the even greater Node ecosystem, which gives you a lot of libraries, code examples, maintenance and improvements. Second, hiring is a major factor. You can assign most current-day web developers onto a RN project with little problems, whereas Flutter is a new language and skill set.
  - cageface 3y ago
    Sure it’s a valid concern. I’m building my own app so hiring isn’t a concern for me. So far I’ve found the Flutter library ecosystem to be more than adequate for my needs and I’m finding it a far more pleasant and productive platform than React Native to work in. I always found RN very easy to get started with but over time as features get added and dependencies evolve RN apps become increasingly difficult to update and maintain. Also React is one of those easy to learn but difficult to master technologies. I’ve interviewed a lot of people claiming to know React that I wouldn’t trust to build anything complex. There are just so many footguns.