What the fuck is the philosophy behind ionic and similar retarded frameworks?
To not to learn two or languages/ecosystems ?
You fucking deal with more in those "hybrid" shits: Ionic itself + Cordova + Angular + Android + iOS
I'd rather write the same code twice and just deal with Android + iOS

Are all other ""Hybrid"" and pseudo-native frameworks like this?

Problem comes from web developers trying to write mobile apps. People are too used to whatever language they use on a day to day basis (hint javascript). Cordova like webview based frameworks are shit - full stop. Other frameworks that port to native code are a “bit” better but from experience I can tell you that whatever way they all work it maxes out the RAM and the device pretty fast with extensive use of the app. On top of that the binary becomes 10x bigger and requires WiFi to download.

If you only need a simple mobile app the you can justify the use of “hybrid” app, but anything more complicated than showing more than 3 screens that involves some business login, and requires back compatibility I’d go native.

My personal conclusion is always use native language for mobile apps you’ll thank me later.

@PappyHans
Fuck, if only I had a choice, I would at least try with react native or similar

@Salim use to work for a company where the CEO was saying to me that he has a friend who runs a similar company and he only pays one developer to write “hybrid” apps. I told him wait 6 months and ask him again how is the app doing. Guess what happens next. App was very unstable and had loads of crashes that were hard to reproduce. It also went to a stage were they needed something more custom that required some specific native code to run that wasn’t possible using what they were using so had to write some spaghetti code that worked half the time. That same CEO had to pay an external agency to re-write the entire app from scratch costing a lot more at the end. I am sure there is more examples out there. To this day I am still looking for a valid reason not to use native code when building mobile apps.

@PappyHans i completely agree with the comfortable language part and unfortunately this is somewhat applicable for the reverse too.

I am so much deep into java, i find even kotlin difficult . And js looks so messed up and difficult and all these frameworks around it bootstrap, typescript, angular, react, backend, i feel like missing a whole part of being a dev :/

@TitanLannister I agree with you. In reality if you want to run some code on a client side you would need to use javascript regardless you like it or not because this is what the browser supports. Why not follow the same logic when building mobile apps?

I can feel your pain coming from strict typed language like Java into something very loose like Javascript and having to wrap your head around it could be time consuming and painful. At the end of the day this is the path you need to take to achieve almost anything that requires dynamic content nowadays. I used Javascript in the past, didn’t like it and I try to steer clear from it for as long as I can. Again personal opinion but that’s why there is other people who like it and are really good in it. Just not my cup of tea

Hybrid apps help in development time even for a mobile developer. I know how to write Android apps, but always choose React Native or Ionic in order to have most UI and state be cross-platform and have hot-reloading. All the heavy-lifting tasks are then provided by mere snippets of native code. This way, you can have most developers working with JavaScript, and call a native developer when special native code is required. This also reduces costs.

@bartmr do you write any unit or UI tests for your apps?

@PappyHans Yeah. Mainly Jest. I don't bother to test native code, since uncaught exceptions are always logged. Heck, there are apps I don't even test and they run fine (of course, with the strictest level of Typescript, and with Sentry running)

I totally agree mate. I only do native mobile dev.
Java and swift are so mature now and i have a ton of code base.
I started and delivered an android app with backend in 1 week !

That is interesting because from all I’ve seen so far from this “native” apps they’re rarely tested properly and have loads of crashes in the memory heap that always lead to a dead end stack traces. I’m happy it worked well for you.

@PappyHans That is why it's best to treat the UI as "a web page" and have the JavaScript engine abstract a bunch of native limitations, and only write what you need in native code.

Out of curiosity what are those native limitations?

@PappyHans memory management, threading, views (using CSS-in-JS abstracts me from having to learn XML or other native styling methodology), async callbacks, state management with time travel (something like Redux is hard in native languages), HTTP requests. Testing is also easier. All these things are limitations in native code. I can't remember more.

@bartmr I can see your point as a web developer. However all of those are easily achieved in native code apart from the time travel Redux like state management for which you would need to use a framework. In fact I don’t see all of the points you mentioned as limitations at all. Multi threading is a lot more flexible and advanced written in native code as you have more control on what gets dispatched where and you can pause, cancel and remove tasks from the queue etc. Making a HTTP request really takes 3 lines of code max for most parts. If you need a time travel state management then your screen might be way too complicated and should be separated out logically. However if there is a reason that you really need that state management you can do it natively as well as I mentioned above. Last I don’t see how this would be easier to test. You have no control on how your js translates into native code never mind testing it. You can only test your js or am I missing something?

@PappyHans There is no native translation for the Javascript code. React Native runs Javascript in development the same way it runs in production: using Chrome's V8 engine. The only difference is, instead of rendering <div>s, it renders Android Views. And you're not going to test what's already an atomic unit in android development. So, there isn't a JavaScript conversion to native code.

Also, most company projects do not require multi-threading, and if they do, you can do it in the few lines of native code you need for that action. Also, managers prefer to tweak stuff right on site than to wait for changes to compile. That's why time-travel is good in these cases. You can go back and forth and review the flow with your manager. Also, the guarantee that they can quickly have a web developer working in the mobile app makes them more at ease.

An important (and often overlooked) benefit of using those tools is not having to write critical logic twice and in two different ways. Sure you can implement the same algorithm in Java, Swift, and in JS, and use server-side implementation as the ultimate truth. But if you're dealing with real-time data you want to receive only partial changes on each end to avoid high load, and merge them into the state exactly the same way regardless of whether it's Android, iOS, web, or server. That is really hard unless you're using a single language, as different languages can and do have nuances regarding data structures and underlying implementations.

@hitko this could also be achieved with proper backend architecture and designed in a way that it only returns the data you need. Trying to fix backend issues on front end always leads to inconsistency and unexpected behaviour. I don’t think the example you gave is actually FE problem. Source of truth should always come from BE since your business logic will run there. Trying to manipulate the data on FE could be a risky since many factors can contribute to errors like database write issues or loss of network just to name a few. Last but not least you can’t control or fully trust user device which is not true for your backend.

@PappyHans If we use simple chat as an example of real-time app: in order for BE to return only the messages needed on FE, BE needs to know exactly which client is at what point in the stream, so that FE can simply append received messages. On the other hand, if BE simply forwards received messages to FE, FE can merge them into the stream the same way BE does, so there's no need to synchronise streams for each message, and if there's an error or delay pushing new message to some clients, sending can be retried on a separate level (say, connection handler) without checking whether BE in the meantime added other messages to the stream and pushed the resulting change to the client.

@hitko that is very true for this example. In such cases you can use web sockets and have the BE push changes and notify subscribers. This way you get what you need only and can append new messages to your list. This again comes to proper BE design and picking the correct tools where needed. FE should only consume and display data coming from BE without modifying it or you’re risking to present incorrect data to your users.

@PappyHans Normally you can just push messages; but what if client doesn't receive them in the same order, and sort implementation on FE isn't the same as on BE? What if FE receives data from multiple sources, e.g. p2p sockets or a cluster of BE servers? Everything you're saying works fine for small-scale apps, but once you go beyond that and find yourself in need of data replication, HA clusters, possibly multiple data centres, there's simply no such thing as "just push a message", your entire data model and business logic has to be designed with that in mind or your app will be about as reliable as Skype.

@hitko true in such cases you can use Kafka that sends messages to HA clusters that then can pass it on further to client side. There is always ways to implement this on BE.

@PappyHans A queue doesn't change a thing about this problem. FIFO queues do deliver messages exactly once and in order, but they're inherently slow and don't scale, while standard messaging queues still can deliver messages multiple times and out of order.