The not so hidden cost of sharing code between iOS and Android • Hacker News Board

Re: The not so hidden cost of sharing code between iOS and Android

#321

Post by The_rationalist » Fri, Aug 16, 2019, 7:29 PM UTC

Diesel555 wrote: post #314

The_rationalist wrote: post #82

Earlier quoted context omitted.

Could you explain what you think of the pros and cons of flutter VS IONIC? I think flutter and it's astonishing number of issues on github + their lack of manpower + their lack of major features + the presence of major performance and behavior bugs + the extremely small lib ecosystem (dart) is a major, useless risk for a startup for the benefit of tech hype. (just my point of view, don't take it personally)

I've been writing in Ionic for a while now. I enjoy their philosophy. They put out their own description of the differences with Flutter (biased I'm sure). https://ionicframework.com/resources/articles/ionic-vs-flutt... Ionic lets me build a web app and publish it to any device pretty easily. I don't have to use their components either... in fact after using Ionic, you may not use Ionic anymore at all. All you need i…

What are the pro and cons of ionic Cordova vs ionic capacitor? How feature complete and stable is capacitor vs Cordova?

Re: The not so hidden cost of sharing code between iOS and Android

#322

Post by pjmlp » Fri, Aug 16, 2019, 8:46 PM UTC

shmerl wrote: post #315

pjmlp wrote: post #310

Earlier quoted context omitted.

What you call lock in, we in the industry call productivity of being able to use SDKs not stuck in 80's UNIX world, full of endless extensions. Instead of shouting from a soap box that no one cares to listen to, get Khronos to actually provide a 21st SDK tooling. Then Sony, Microsoft, Nintendo (Vulkan is 2nd class on the Switch), Apple, Hollywood and all their partners might care. Until then, the wind takes it all.

You know what lock-in is, so no point in pretending you don't understand what its problems are. It's not about productivity, it's about anti-competitive jerks who use development tools to hamper competition. Of course those who push lock-in like to present it as a positive thing and hide its real nature, but it's just a smokescreen which is easy to see through. Once in a while, they just can't help it, and express th…

Jerks, shills, ....

Plenty of nice words for someone that advocates APIs that are portable only on paper, as the best features are all hidden away on OEM specific extensions, leading to multiple incompatible code paths.

Psst, lets not reveal the Achilles heel from the soap box.

As for Dan Baker, enjoy.

"Benefits of DirectX 12 on Ashes of Singularity"

https://youtu.be/9cvmDjVYSNk

Re: The not so hidden cost of sharing code between iOS and Android

#323

Post by shmerl » Fri, Aug 16, 2019, 8:55 PM UTC

pjmlp wrote: post #322

shmerl wrote: post #315

Earlier quoted context omitted.

You know what lock-in is, so no point in pretending you don't understand what its problems are. It's not about productivity, it's about anti-competitive jerks who use development tools to hamper competition. Of course those who push lock-in like to present it as a positive thing and hide its real nature, but it's just a smokescreen which is easy to see through. Once in a while, they just can't help it, and express th…

Jerks, shills, .... Plenty of nice words for someone that advocates APIs that are portable only on paper, as the best features are all hidden away on OEM specific extensions, leading to multiple incompatible code paths. Psst, lets not reveal the Achilles heel from the soap box. As for Dan Baker, enjoy. "Benefits of DirectX 12 on Ashes of Singularity" https://youtu.be/9cvmDjVYSNk

Whitewashing lock-in is pretty much a shill thing. And pushing it on others is a jerk one.

As for Dan Baker, he meant low level APIs, not DX12 in particular. He explicitly said, that MS only API is harmful for developers, and non lock-in one is needed. Not surprisingly, Ashes of the Singularity is in the process of getting rid of DX12 for Vulkan. Have fun trying to dismiss it.

Re: The not so hidden cost of sharing code between iOS and Android

#324

Post by pjmlp » Fri, Aug 16, 2019, 9:18 PM UTC

shmerl wrote: post #323

pjmlp wrote: post #322

Earlier quoted context omitted.

Jerks, shills, .... Plenty of nice words for someone that advocates APIs that are portable only on paper, as the best features are all hidden away on OEM specific extensions, leading to multiple incompatible code paths. Psst, lets not reveal the Achilles heel from the soap box. As for Dan Baker, enjoy. "Benefits of DirectX 12 on Ashes of Singularity" https://youtu.be/9cvmDjVYSNk

Whitewashing lock-in is pretty much a shill thing. And pushing it on others is a jerk one. As for Dan Baker, he meant low level APIs, not DX12 in particular. He explicitly said, that MS only API is harmful for developers, and non lock-in one is needed. Not surprisingly, Ashes of the Singularity is in the process of getting rid of DX12 for Vulkan. Have fun trying to dismiss it.

Ah, still being creative with names, I should offer you a name calling dictionary.

I don't need to dismiss anything, the industry giants haven spoken, multiple times since the early 80's on graphics API adoption.

Nice way to avoid talking about lock-in in OpenGL, WebGL and Vulkan OEM private extensions.

As for Dan Baker, you put words on his mouth, while I show him actually speaking....

Re: The not so hidden cost of sharing code between iOS and Android

#325

Post by shmerl » Fri, Aug 16, 2019, 10:03 PM UTC

pjmlp wrote: post #324

shmerl wrote: post #323

Earlier quoted context omitted.

Whitewashing lock-in is pretty much a shill thing. And pushing it on others is a jerk one. As for Dan Baker, he meant low level APIs, not DX12 in particular. He explicitly said, that MS only API is harmful for developers, and non lock-in one is needed. Not surprisingly, Ashes of the Singularity is in the process of getting rid of DX12 for Vulkan. Have fun trying to dismiss it.

Ah, still being creative with names, I should offer you a name calling dictionary. I don't need to dismiss anything, the industry giants haven spoken, multiple times since the early 80's on graphics API adoption. Nice way to avoid talking about lock-in in OpenGL, WebGL and Vulkan OEM private extensions. As for Dan Baker, you put words on his mouth, while I show him actually speaking....

> I don't need to dismiss anything As for Dan Baker, you put words on his mouth

Sure, keep pretending it didn't happen. Totally not a shill thing to do ;)

Re: The not so hidden cost of sharing code between iOS and Android

#326

Post by Diesel555 » Sat, Aug 17, 2019, 1:06 AM UTC

The_rationalist wrote: post #321

Diesel555 wrote: post #314

Earlier quoted context omitted.

I've been writing in Ionic for a while now. I enjoy their philosophy. They put out their own description of the differences with Flutter (biased I'm sure). https://ionicframework.com/resources/articles/ionic-vs-flutt... Ionic lets me build a web app and publish it to any device pretty easily. I don't have to use their components either... in fact after using Ionic, you may not use Ionic anymore at all. All you need i…

What are the pro and cons of ionic Cordova vs ionic capacitor? How feature complete and stable is capacitor vs Cordova?

Cordova is time tested and has a large community behind it. I choose Capacitor if it's available and then go to Cordova if it's not. Ionic has a collection of easy to use Cordova plugins (https://ionicframework.com/docs/native/overview). I have honestly found they they are not that well maintained. I ran into enough issues that I avoid them if I can. To be fair, the contributors are people contributing on their own free time with no financial incentive. Hence, I choose Capacitor when I can. They have a financial incentive (Ionic is open about this https://ionicframework.com/blog/ionic-2019-business-update/)

I joined when Capacitor was in beta and figured I'd use the up and coming. From research, it appeared there was a good reason Ionic created their own product. They didn't do it to simply stop using a tried and true product.

Also to be clear, Cordova is not an Ionic product. It was a great community thing for a while to talk to native devices.

Re: The not so hidden cost of sharing code between iOS and Android

#327

Post by eridius » Sat, Aug 17, 2019, 2:03 AM UTC

pjmlp wrote: post #312

eridius wrote: post #311

Earlier quoted context omitted.

Metal shaders != Metal API. Metal API is Obj-C. Metal shaders are written in MSL (Metal Shading Language). C++ is still not involved, though MSL is admittedly based on C++.

Metal API ⊇ Metal Shaders, it is useless without them. https://developer.apple.com/metal/Metal-Shading-Language-Spe... "The Metal programming language is a C++14-based Specification with extensions and restrictions. Refer to the C++14 Specification (also known as the ISO/IEC JTC1/SC22/WG21 N4431 Language Specification) for a detailed description of the language grammar. This section and its subsections describe the m…

I don't know what point you're trying to make. MSL doesn't link with the rest of your program. No matter what language you use for your program, the shaders are written in MSL. For my program if I use Rust or C++ or Obj-C or Swift or a microscopic magnet and a very careful hand, I write my Metal shaders in MSL.

Re: The not so hidden cost of sharing code between iOS and Android

#328

Post by michaelchisari » Sat, Aug 17, 2019, 3:48 AM UTC

weavie wrote: post #222

scotth wrote: post #191

Earlier quoted context omitted.

What specifically isn't elegant about Dart in your opinion? Seems like a perfectly good language to me, and although it's nothing fancy, it does have a bit of sugar, and a solid standard library. I also like how codegen and static analysis are so accessible through the build libraries. It's evolving pretty quickly, too. Non-nullable by default is coming up, along with extension methods, FFI. Possibly implicit convers…

I think I've been spoiled by algebraic data types and pattern matching. I really miss them. Non-nullable by default will be a huge win. It does feel like a huge step backwards having to deal with nulls again.

Non-nullable types are coming.

https://www.youtube.com/watch?v=J5DQRPRBiFI&feature=youtu.be...

Re: The not so hidden cost of sharing code between iOS and Android

#329

Post by scarlac » Sat, Aug 17, 2019, 6:37 AM UTC

K0nserv wrote: post #302

scarlac wrote: post #282

Earlier quoted context omitted.

Some of your statements are partially correct, but a few of these assertions are flat out false for React Native. Let's look at them: > - Binary size. A basic Flutter/RN app easily pushes you past 20MB in app size on iOS, whereas a complex and complete app like Tweetbot is ~7MB. I have working examples of fairly complex production applications that are > - Poor accessibility. Native iOS apps get a lot of accessibilit…

> I have working examples of fairly complex production applications that are Fair, the problem isn't as bad for RN, for Flutter it's still very bad though. > False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely…

> failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader

Appreciate that you looked into it. On iOS and you do not need to set anything to become screen reader friendly _in React Native_. The default TouchableOpacity with a simple piece of text inside of it will become focusable and iOS will read the text aloud for you. This works because RN uses native elements unlike Flutter, Electron, and others.

In fact, I took you up on the claim that it wouldn't read correctly. I used my app just now which has never been tested or optimized for accessibility. Covered my eyes and began navigating. It works just fine! All tappable elements are indeed read aloud. I was able to navigate through the app settings, change them, go back, and reload other screens, navigate to the updated content, and perform actions on the new content.

Please do not put RN in the same bucket as Flutter or Electron. They are fundamentally differently.

Re: The not so hidden cost of sharing code between iOS and Android

#330

Post by pjmlp » Sat, Aug 17, 2019, 7:38 AM UTC

eridius wrote: post #327

pjmlp wrote: post #312

Earlier quoted context omitted.

Metal API ⊇ Metal Shaders, it is useless without them. https://developer.apple.com/metal/Metal-Shading-Language-Spe... "The Metal programming language is a C++14-based Specification with extensions and restrictions. Refer to the C++14 Specification (also known as the ISO/IEC JTC1/SC22/WG21 N4431 Language Specification) for a detailed description of the language grammar. This section and its subsections describe the m…

I don't know what point you're trying to make. MSL doesn't link with the rest of your program. No matter what language you use for your program, the shaders are written in MSL. For my program if I use Rust or C++ or Obj-C or Swift or a microscopic magnet and a very careful hand, I write my Metal shaders in MSL.

1 - MSL is a set of extensions on top of C++14

2 - Metal requires MSL

3 - IO Kit is a C++ framework for macOS, iOS, iPadOS and watchOS drivers

4 - Metal GPGPU drivers are written in IO Kit

5 - Metal is useless without MSL and GPGPU drivers

6 - Ergo, Metal requires C++