9 ms·

Is there a reason for users to care about this at all? Because it seems to me that this just solves problems for developers while making the user experience wor

by IBM 9y ago

Is there a reason for users to care about this at all? Because it seems to me that this just solves problems for developers while making the user experience worse or not as good as it could be. The same goes for Electron-based apps.

andreashansen 9y ago
Watch the State of the Web talk from Google IO 2017. Certain native apps (Twitter, OLA) are 70-100MB in size when downloaded from the app stores. Their progressive web app version are 0.2-0.6MB. Extremely important in countries with very limited and/or expensive mobile data.
- jvzr 9y ago
  I'd say that's another issue. Duplicate frameworks in Facebook.app, monolithic tracking frameworks, etc. So much useless stuff prying on the user's privacy. I remember Twitter.app had code to get the currently installed apps, to "better target ads." It's user hostile and we are paying with the multi gigabytes of data.
  - euyyn 9y ago
    The argument can't go only one way, though. If a web app doesn't get the UI in tune with the OS' look and feel, "the developer should be bothered to create a native app". But if a native app is a massive bloat, "that's another issue".
- akmarinov 9y ago
  https://sensortower.com/blog/ios-app-size-growth https://sensortower.com/blog/ios-app-size-growth According to this, Facebook was 32 MBs 4 years ago. It's similar with Twitter. It's their fault that they keep adding stuff to track you. And Facebook contains just about every library that has ever existed now.
  - pavlakoos 9y ago
    But now Facebook mobile app is a different tech. It's ReactNative, not Obj-C, right?
    - jaxondu 9y ago
      React Native under the hood uses Obj-C to bridge to native Cocoa frameworks. For example when you uses a <View> tag in JavaScript, it ends up calling iOS UIView.
      - pavlakoos 9y ago
        Still, it's not the very same tech. Especially in this discussion, where we are talking about apps performance and languages, which need to get under the hood instead of talking directly with the engine, are presented as "worse".
    - LeoNatan25 9y ago
      Only a tiny fraction of the Facebook app is actually RN. Messenger uses none of it for performance reasons.
      - pavlakoos 9y ago
        Huh? Isn't Facebook advertising their main app as no.1 use case of ReactNative?
        LeoNatan25 9y ago
        Advertising is one thing, reality is different. The main, performant views are native. Some of the esoteric stuff is RN.
- maxsilver 9y ago
  That doesn't have anything to do with native vs web though. Twitter's native app is heavier than their web app because Twitter has historically filled the native app with junk (like a fullscreen video just for the login screen, "moments", "highlights", hijacking browser URLs, a bunch of ads and ad tracking, etc). Facebook does the same, to an almost silly degree - https://news.ycombinator.com/item?id=8162342 https://news.ycombinator.com/item?id=8162342 The Twitter client could easily be ~3MB on Android, for instance, if they just stripped the garbage out. And similarly, if you take a web app, and embed all that same junk into it, it will suddenly be a heavy download too.
  - euyyn 9y ago
    In theory you could make a web app look like a native iOS app too, yet in practice developers don't either.
    - s73ver 9y ago
      In practice, they tend to make it look like iOS, but then they ship the same thing for Android, meaning the Android app looks like an iOS app.
- gpawl 9y ago
  0.6MB to launch the app, which downloads 100MB more resources as soon as it starts up.
jvzr 9y ago
Exactly. I don't want websites to send notifications. And I dislike websites with Offline support: I always have to refresh twice to make sure the content I'm seeing came from a fresh source and not from cache.
- pluma 9y ago
  Then just deny push notifications when the website prompts for them (exactly once). And simply refresh manually to make sure the offline-available website is fresh. It's not like you're being force-fed notifications against your will. And it's not like offline content hurts you. Any inconvenience offline support causes to you pales in comparison to how much people benefit who actually need to be able to access content on spotty connections.
  - jvzr 9y ago
    Offline makes sense, you are right. I'm being privileged. But for notifications, even the only-once* prompt is an annoyance we never had to deal with before. It's like the European Cookies Law: great in essence, but when every website bugs you about it then the problem has been exacerbated, not solved. I don't care about receiving notifications for a website I visit once in a blue moon, and I especially don't care to be even asked. There should be an action that triggers the prompt, like some kind of opt-in. Edit: same with "app banners" *it never is, because cross platform, multiple devices, multiple browsers. A fucking pain.
- egeozcan 9y ago
  Why is your complaint specific to websites with offline support? I always get stale data when I open Twitter app. I have to go to the top and refresh to get new tweets (and then they serve you with even more stale tweets but that's another problem).
  - jvzr 9y ago
    It's very specific and I realize I'm being privileged. I don't think my argument holds much ground. My thing is: I visit a particular website to get the latest news on a topic but it's done with some kind of poorly coded implementation of offline cache. Despite my privileged, first-world, 4G-everywhere connection, it insists on loading stale data even though it looks exactly like a regular website. And this clashes with my vision of internet, which is, as others said, regular pages with hyperlinks, and a Refresh refreshes the page to get the newest version, even if it's stale. If things haven't changed, then they haven't and I instantly know nothing's new. As I've said, pretty minor and I realize that Offline mode has much more pros than cons.
pluma 9y ago
Push notifications? Every single messenger or anything that lets you set reminders. Note that features like push notifications are implemented with a discrete opt-in on every other platform already. Don't want notifications? Just say "Deny" when you're prompted. Offline support? Only if you happen to live in the 99.99% of the world that doesn't have 24/7 perfect WiFi/4G coverage with unlimited data. If you've ever kept a page open in the background and wished the data would still be there when you come back, offline support could have helped with that. The choice is not between a native and a web app. The choice is between a web app or no app. There are certainly apps that could cease developing platform specific native apps when PWAs are supported on iOS but the vast majority of apps that benefit from PWAs being supported universally are apps that simply would never be available as native apps (let alone native apps on more than one platform).
- IBM 9y ago
  All of these things are already available in native apps. Putting aside all the business reasons for why Apple wouldn't want to do this, why should Apple spend any time to enable this for web apps? You say the choice is between a web app and no app, and I'm sure on the margin this impacts companies that can't afford to create a native app, but why should Apple cater to the lowest common denominator? Steve Jobs' post on Flash addresses this specifically [1]: >Sixth, the most important reason. Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices. We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers. This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms. Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X. Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform. [1] https://www.apple.com/hotnews/thoughts-on-flash/ https://www.apple.com/hotnews/thoughts-on-flash/
jbigelow76 9y ago
>The same goes for Electron-based apps. When it comes to Electron apps I think any failing to provider a top notch user experience is on the developer and not on the technology. Visual Studio Code is based on Electron and it is hands down the best text editor/IDE-lite out there because the team behind it put the time in to make seem like the type of app you would get out established UI frameworks within the target environment.
- pjmlp 9y ago
  It might be faster than Atom, but it surely feels sluggish compared with other native editors on my system. I only put up with it due to being the editor with the best support for Rust plugins. The day I can have the same experience on Emacs for Rust, VSCode gets kicked out.
- LeoNatan25 9y ago
  Code is not native. Where is the accessibility support? Native tabs? Performance? Look and feel? Compared to something like BBEdit, Code is a joke.
slaymaker1907 9y ago
What you fail to understand is that what is good for developers is good for users. Instead of spending resources on maintaining many different code bases, developers can focus on providing a more solid set of features for one. For instance, maybe instead of being an always online application, they can put in effort at caching for offline use instead of duplicating features across different platforms. I did my senior project in Electron and there was no way we could have implemented as much as we did if we had to build a native solution for every platform.

by IBM 9y ago

andreashansen 9y ago

Watch the State of the Web talk from Google IO 2017. Certain native apps (Twitter, OLA) are 70-100MB in size when downloaded from the app stores. Their progressive web app version are 0.2-0.6MB. Extremely important in countries with very limited and/or expensive mobile data.

jvzr 9y ago
I'd say that's another issue. Duplicate frameworks in Facebook.app, monolithic tracking frameworks, etc. So much useless stuff prying on the user's privacy. I remember Twitter.app had code to get the currently installed apps, to "better target ads." It's user hostile and we are paying with the multi gigabytes of data.
- euyyn 9y ago
  The argument can't go only one way, though. If a web app doesn't get the UI in tune with the OS' look and feel, "the developer should be bothered to create a native app". But if a native app is a massive bloat, "that's another issue".
akmarinov 9y ago
https://sensortower.com/blog/ios-app-size-growth https://sensortower.com/blog/ios-app-size-growth According to this, Facebook was 32 MBs 4 years ago. It's similar with Twitter. It's their fault that they keep adding stuff to track you. And Facebook contains just about every library that has ever existed now.
- pavlakoos 9y ago
  But now Facebook mobile app is a different tech. It's ReactNative, not Obj-C, right?
  - jaxondu 9y ago
    React Native under the hood uses Obj-C to bridge to native Cocoa frameworks. For example when you uses a <View> tag in JavaScript, it ends up calling iOS UIView.
    - pavlakoos 9y ago
      Still, it's not the very same tech. Especially in this discussion, where we are talking about apps performance and languages, which need to get under the hood instead of talking directly with the engine, are presented as "worse".
  - LeoNatan25 9y ago
    Only a tiny fraction of the Facebook app is actually RN. Messenger uses none of it for performance reasons.
    - pavlakoos 9y ago
      Huh? Isn't Facebook advertising their main app as no.1 use case of ReactNative?
      - LeoNatan25 9y ago
        Advertising is one thing, reality is different. The main, performant views are native. Some of the esoteric stuff is RN.
maxsilver 9y ago
That doesn't have anything to do with native vs web though. Twitter's native app is heavier than their web app because Twitter has historically filled the native app with junk (like a fullscreen video just for the login screen, "moments", "highlights", hijacking browser URLs, a bunch of ads and ad tracking, etc). Facebook does the same, to an almost silly degree - https://news.ycombinator.com/item?id=8162342 https://news.ycombinator.com/item?id=8162342 The Twitter client could easily be ~3MB on Android, for instance, if they just stripped the garbage out. And similarly, if you take a web app, and embed all that same junk into it, it will suddenly be a heavy download too.
- euyyn 9y ago
  In theory you could make a web app look like a native iOS app too, yet in practice developers don't either.
  - s73ver 9y ago
    In practice, they tend to make it look like iOS, but then they ship the same thing for Android, meaning the Android app looks like an iOS app.
gpawl 9y ago
0.6MB to launch the app, which downloads 100MB more resources as soon as it starts up.

jvzr 9y ago

Exactly. I don't want websites to send notifications. And I dislike websites with Offline support: I always have to refresh twice to make sure the content I'm seeing came from a fresh source and not from cache.

pluma 9y ago
Then just deny push notifications when the website prompts for them (exactly once). And simply refresh manually to make sure the offline-available website is fresh. It's not like you're being force-fed notifications against your will. And it's not like offline content hurts you. Any inconvenience offline support causes to you pales in comparison to how much people benefit who actually need to be able to access content on spotty connections.
- jvzr 9y ago
  Offline makes sense, you are right. I'm being privileged. But for notifications, even the only-once* prompt is an annoyance we never had to deal with before. It's like the European Cookies Law: great in essence, but when every website bugs you about it then the problem has been exacerbated, not solved. I don't care about receiving notifications for a website I visit once in a blue moon, and I especially don't care to be even asked. There should be an action that triggers the prompt, like some kind of opt-in. Edit: same with "app banners" *it never is, because cross platform, multiple devices, multiple browsers. A fucking pain.
egeozcan 9y ago
Why is your complaint specific to websites with offline support? I always get stale data when I open Twitter app. I have to go to the top and refresh to get new tweets (and then they serve you with even more stale tweets but that's another problem).
- jvzr 9y ago
  It's very specific and I realize I'm being privileged. I don't think my argument holds much ground. My thing is: I visit a particular website to get the latest news on a topic but it's done with some kind of poorly coded implementation of offline cache. Despite my privileged, first-world, 4G-everywhere connection, it insists on loading stale data even though it looks exactly like a regular website. And this clashes with my vision of internet, which is, as others said, regular pages with hyperlinks, and a Refresh refreshes the page to get the newest version, even if it's stale. If things haven't changed, then they haven't and I instantly know nothing's new. As I've said, pretty minor and I realize that Offline mode has much more pros than cons.

pluma 9y ago

Push notifications? Every single messenger or anything that lets you set reminders. Note that features like push notifications are implemented with a discrete opt-in on every other platform already. Don't want notifications? Just say "Deny" when you're prompted. Offline support? Only if you happen to live in the 99.99% of the world that doesn't have 24/7 perfect WiFi/4G coverage with unlimited data. If you've ever kept a page open in the background and wished the data would still be there when you come back, offline support could have helped with that. The choice is not between a native and a web app. The choice is between a web app or no app. There are certainly apps that could cease developing platform specific native apps when PWAs are supported on iOS but the vast majority of apps that benefit from PWAs being supported universally are apps that simply would never be available as native apps (let alone native apps on more than one platform).

IBM 9y ago
All of these things are already available in native apps. Putting aside all the business reasons for why Apple wouldn't want to do this, why should Apple spend any time to enable this for web apps? You say the choice is between a web app and no app, and I'm sure on the margin this impacts companies that can't afford to create a native app, but why should Apple cater to the lowest common denominator? Steve Jobs' post on Flash addresses this specifically [1]: >Sixth, the most important reason. Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices. We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers. This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms. Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X. Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform. [1] https://www.apple.com/hotnews/thoughts-on-flash/ https://www.apple.com/hotnews/thoughts-on-flash/

jbigelow76 9y ago

>The same goes for Electron-based apps. When it comes to Electron apps I think any failing to provider a top notch user experience is on the developer and not on the technology. Visual Studio Code is based on Electron and it is hands down the best text editor/IDE-lite out there because the team behind it put the time in to make seem like the type of app you would get out established UI frameworks within the target environment.

pjmlp 9y ago
It might be faster than Atom, but it surely feels sluggish compared with other native editors on my system. I only put up with it due to being the editor with the best support for Rust plugins. The day I can have the same experience on Emacs for Rust, VSCode gets kicked out.
LeoNatan25 9y ago
Code is not native. Where is the accessibility support? Native tabs? Performance? Look and feel? Compared to something like BBEdit, Code is a joke.

slaymaker1907 9y ago

What you fail to understand is that what is good for developers is good for users. Instead of spending resources on maintaining many different code bases, developers can focus on providing a more solid set of features for one. For instance, maybe instead of being an always online application, they can put in effort at caching for offline use instead of duplicating features across different platforms. I did my senior project in Electron and there was no way we could have implemented as much as we did if we had to build a native solution for every platform.