4 ms·

Can you explain more the part about native apps being hard to make? I mean, I can open Xcode, start a new project, hit run, and there's an app ready to go, with

Can you explain more the part about native apps being hard to make? I mean, I can open Xcode, start a new project, hit run, and there's an app ready to go, with a simulator and everything. It has API's that allow safe access to OS-level resources. It has powerful multi-threading, built-in views that I can reuse (like collections), stack based browsing is native, etc... Also, the client is not broken by default (I.e. client apps in the browser are by default spyware, at a technical level). All the weird tooling that exists around actually getting html + js + css to work like an app is an indication to the contrary. The constantly evolving ecosystems is an indication of reaching stability, not having yet achieved it. I will say though that targeting different platforms is an issue, which is not the same thing as your claim. Yes, targeting all platforms is hard, but I don't think any one native app ecosystem is really any harder than web. I do think there's a lot of survivor bias from people whose job it is to build apps with web technologies. And to your point that "it won". I don't think anyone, even lay-people, like electron-based apps. It's just what they have to use because there is an infinite amount of web developers. However, I feel that it's a bit premature to call call something that's ubiquitous that everyone hates as "winning". Also, the most used software as a matter of time on task would probably be excel, email clients, and web browsers. All of these are built natively. So with the exception of slack, and taking a broad view of the road that lies ahead, most of the stuff that's built on electron is sort of vapor in the grand scheme of things. I think we can actually expect to see more and more native apps, due to power consumption requirements. I stopped using Chrome years ago due to its aggressive power/memory consumption and never actually really looked back. Any way, sorry for the unnecessarily long response, but seriously what you're saying is very hyperbolic. We are literally just at the beginning of the absolute beginning in terms of what technology is going to look like. Things will be very different in 5 years and super different in 10-20 years.

fiatjaf 5y ago
I agree. Writing native apps is very easy once you get mildly used to any framework for writing native apps. The "web" is just another framework, a very popular one, but also one that is very bloated and hard-to-use.
- thehappypm 5y ago
  For one, you need Xcode, which means you need specific hardware.
  - fiatjaf 5y ago
    You need specific hardware to be able to publish Electron apps for Mac too.
    - aniforprez 5y ago
      With electron I can actually just build the apps for the other platforms and then do specific platform level changes (if required) for Mac. For native apps, I literally cannot even begin to code anything unless I have access to hardware
      - fiatjaf 5y ago
        This is not true, most languages are multiplatform. And there are dozen of multiplatform native GUI frameworks out there. Flutter is one of them, the other ones I cited too.
shaolinspirit 5y ago
from my experience the struggle with making native apps is in implementing all of the services that are in browser environment out-of-box manually. image caching, websocket handling etc. which enables more fine tuning for the end product, where in html you can put img tag and that little thing will fetch the image for you, store it somewhere and render in accordance with some layout structure. in mobile dev you need to do more so to say, low level stuff in comparison with browser.
- asimpletune 5y ago
  Well they're definitely very different technologies too, and the things that you mention, in that specific context, are what the web was actually designed to do well. Basically, the web is purpose built for digital publishing. This is really good for content, as it allows the publishers to update the content and leave the client relatively the same. Your example of an <img> is a perfect one. Yes, if all the images are going to be loaded remotely, I would say this is a client/server messaging paradigm, and one that excels in digital publishing. However, if you're going to build an app (which is what we're talking about), then you are probably going to want to store the app's images in one giant executable... which means all the caching and everything you want is going to be extremely fast, probably much faster than what the browser will do for the same task. If you really want to understand what I mean, just ask yourself "what is the life-cycle of a web app", e.g. what is the "main" method? Are there clearly defined transitions between views? What is the execution/memory model? When you answer those questions you realize that the browser was built to display pages of text and images, loaded by a server. From there it should be clear why people don't think there's any comparison when it comes to building apps, because one was designed for it and the other inherited that responsibility. I'm not saying web development as a paradigm isn't popular, but I'm arguing against it being easier than native because it's not really. However, if you wanted to add like a digital publishing component to an app, I'd just embed it into a web view, which is the best technical choice.

fiatjaf 5y ago

I agree. Writing native apps is very easy once you get mildly used to any framework for writing native apps. The "web" is just another framework, a very popular one, but also one that is very bloated and hard-to-use.

thehappypm 5y ago
For one, you need Xcode, which means you need specific hardware.
- fiatjaf 5y ago
  You need specific hardware to be able to publish Electron apps for Mac too.
  - aniforprez 5y ago
    With electron I can actually just build the apps for the other platforms and then do specific platform level changes (if required) for Mac. For native apps, I literally cannot even begin to code anything unless I have access to hardware
    - fiatjaf 5y ago
      This is not true, most languages are multiplatform. And there are dozen of multiplatform native GUI frameworks out there. Flutter is one of them, the other ones I cited too.

shaolinspirit 5y ago

from my experience the struggle with making native apps is in implementing all of the services that are in browser environment out-of-box manually. image caching, websocket handling etc. which enables more fine tuning for the end product, where in html you can put img tag and that little thing will fetch the image for you, store it somewhere and render in accordance with some layout structure. in mobile dev you need to do more so to say, low level stuff in comparison with browser.

asimpletune 5y ago
Well they're definitely very different technologies too, and the things that you mention, in that specific context, are what the web was actually designed to do well. Basically, the web is purpose built for digital publishing. This is really good for content, as it allows the publishers to update the content and leave the client relatively the same. Your example of an <img> is a perfect one. Yes, if all the images are going to be loaded remotely, I would say this is a client/server messaging paradigm, and one that excels in digital publishing. However, if you're going to build an app (which is what we're talking about), then you are probably going to want to store the app's images in one giant executable... which means all the caching and everything you want is going to be extremely fast, probably much faster than what the browser will do for the same task. If you really want to understand what I mean, just ask yourself "what is the life-cycle of a web app", e.g. what is the "main" method? Are there clearly defined transitions between views? What is the execution/memory model? When you answer those questions you realize that the browser was built to display pages of text and images, loaded by a server. From there it should be clear why people don't think there's any comparison when it comes to building apps, because one was designed for it and the other inherited that responsibility. I'm not saying web development as a paradigm isn't popular, but I'm arguing against it being easier than native because it's not really. However, if you wanted to add like a digital publishing component to an app, I'd just embed it into a web view, which is the best technical choice.