7 ms·

I've seen this sentiment a few times: "don't try to replicate native apps in the browser." Which makes sense from the standpoint that the browser is just gettin

by anp 11y ago

I've seen this sentiment a few times: "don't try to replicate native apps in the browser." Which makes sense from the standpoint that the browser is just getting ridiculous, like a mini-OS unto itself. However, web apps also allow organizations to write once for many platforms in a much more seamless way than most cross-platform native toolkits I've seen. It's the same reason that desktop Java was in vogue for a little while: you only have to write one UI, and you can run it from a HTTP connection with almost no local permissions. Of course, this was (and still is) a security nightmare, but browsers now do a pretty good job of sandboxing individual code blobs, and also do a pretty good job of abstracting away the native UI. Web apps also provide low or zero installation overhead (low friction to getting a user onboarded/working/monetized/whatever). It would be nice to see some progressive enhancement folks address how to resolve these pain points on the native side, rather than just saying web shouldn't be like native.

ebauch 11y ago
Totally agree. Just look at the mess with mobile OS. It is nearly impossible to develop a native app yourself without excluding half of the world population. In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along.
- AlexandrB 11y ago
  > In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along. As primarily a user of mobile apps I would mind. A web app experience is at the mercy of the network I happen to be connected to. In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS.
  - JoshTriplett 11y ago
    > A web app experience is at the mercy of the network I happen to be connected to. That's one of many things that web apps have been fixing. It's entirely possible to write an offline-capable web app. > In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS. They do, however, look like web apps everywhere, and if you primarily use web apps, you'll feel right at home.
    - vezzy-fnord 11y ago
      Except the complaint about inconsistencies in native UI toolkits to argue in favor of web apps makes no sense, since by definition web apps have no singular look and feel whatsoever beyond the basic semantics of hypertext and browser navigation -- assuming the app doesn't break them. (and then WIMP has its own mostly consistent semantics too)
    - rimantas 11y ago
      > It's entirely possible to write an offline-capable web app. Yeah. It is entirely possible to make web app do a lot of things. Even do them cross-platform. Even to get almost native feel. But when you are done doing it you understand, that going native even on each platform would be faster and cheaper.
      - genericallyloud 11y ago
        And thus the reasons to keep trying to improve those stories. Offline is import for applications. Many web applications make perfect sense to also work offline, and if that can be done easily, then what's the argument? I'd agree that looking like a native app by matching look and feel is probably not a great plan, but I also just fundamentally don't understand the attitude of saying that the web should be relegated to blogs/news/wikipedia style pages and leave everything else to native app silos.
- immibis 11y ago
  I guess by that reasoning desktop apps should go away too, and we should all run ChromeOS.
pjc50 11y ago
We need a viewport-size-agnostic graphical native sandbox that works on x86_64 and ARM, and can be reasonably sure is escape-proof. Which is hard to do if you let it have multitasking and access to graphics drivers. Then we need a means of letting it have just enough network access to be useful but not enough to exploit the rest of your system, bearing in mind the discussion of WebRTC going on at the moment.
- dikaiosune 11y ago
  Isn't this kind of what most browsers are currently doing?
adrusi 11y ago
The cross platform experience will never match the native experience. Think about on the desktop. The only cross platform apps that behave natively on Mac, Windows, GNOME (and derivatives) and KDE are apps tha have completely separate front-ends for every platform. Firefox is an ok example of this, although it in a way forms its own platform rather than integrating with its host, still it pulls it off better than other cross-platform apps. The Transmission bittorrent client is perhaps a better example, it has at least 4 mature front ends: gtk, qt, cli and os x. This is only feasible for a little free software project like Transmission because its UI is fairly simple, it has a list of torrents, a settings dialog and a properties panel. Most apps that try to be cross platform just use a UI toolkit that acts as a cross platform compatability layer. Qt, GTK, Swing, WxWidgets and Tk all fit the bill. The result is that the app doesn't look good or integrate especially deeply into any platform, except sometimes with the platform the the developers personally use. There are few exceptions to this rule. One is Sublime Text 2+ which is built on Qt. Without any customization, its theme looks OK, but doesn't match the design language of any platform, and its integration with its host platform is non-existant, everything happens within the sublime text window (no notifications or system tray/menubar widgets, no quick-view previews in Finder or Nautilus, etc). It's possible to improve integration by intstalling a custom theme which lets the user override a lot of the UI design, including the margins and padding, and plugins are written in python and can access a lot of host platform features. If you want a native experience, you have to write a native app. You can share your business logic by linking to the same C++ code or in the future maybe by using react native and sharing the same non-view code. But your UI-layer has to be tailored specifically to the host platform in order to look good.
- dikaiosune 11y ago
  Agree completely, what I'm seeing though is "web" being the new native for a whole lot of apps. It's familiar to users across platforms, it usually looks good, and while it might not integrate with the host environment, it provides many aspects of the native experience.
- tonyarkles 11y ago
  We have the same philosophy. Most of my experience here is with iOS and Android, but also a bit of Windows/Linux/Mac. If it's going to feel polished, then it's going to need a separate UI front-end for each platform. It's not that there's not yet a sufficiently good cross-platform library; it's that an Android app and an iOS app are different! They're structured differently! And if you try to use an x-platform library, you're going to end up with an iOS-app-that-runs-on-Android, or an Android-app-that-runs-on-iOS, or a this-app-doesn't-feel-right-anywhere. My approach varies based on the application, but in general one of two things end up happening: either the majority of the processing gets pushed onto a server with a well-defined REST API, or the processing gets put in a C++ library that gets linked everywhere (with JNI shims, ctypes shims, whatever's needed to load it in the appropriate environment). This approach does a few things: it ensures that you've got a UI that fits every platform, it improves code quality (you can't add a chunk of business logic in your view handler), and it makes porting so much easier.

by anp 11y ago

ebauch 11y ago

Totally agree. Just look at the mess with mobile OS. It is nearly impossible to develop a native app yourself without excluding half of the world population. In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along.

AlexandrB 11y ago
> In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along. As primarily a user of mobile apps I would mind. A web app experience is at the mercy of the network I happen to be connected to. In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS.
- JoshTriplett 11y ago
  > A web app experience is at the mercy of the network I happen to be connected to. That's one of many things that web apps have been fixing. It's entirely possible to write an offline-capable web app. > In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS. They do, however, look like web apps everywhere, and if you primarily use web apps, you'll feel right at home.
  - vezzy-fnord 11y ago
    Except the complaint about inconsistencies in native UI toolkits to argue in favor of web apps makes no sense, since by definition web apps have no singular look and feel whatsoever beyond the basic semantics of hypertext and browser navigation -- assuming the app doesn't break them. (and then WIMP has its own mostly consistent semantics too)
  - rimantas 11y ago
    > It's entirely possible to write an offline-capable web app. Yeah. It is entirely possible to make web app do a lot of things. Even do them cross-platform. Even to get almost native feel. But when you are done doing it you understand, that going native even on each platform would be faster and cheaper.
    - genericallyloud 11y ago
      And thus the reasons to keep trying to improve those stories. Offline is import for applications. Many web applications make perfect sense to also work offline, and if that can be done easily, then what's the argument? I'd agree that looking like a native app by matching look and feel is probably not a great plan, but I also just fundamentally don't understand the attitude of saying that the web should be relegated to blogs/news/wikipedia style pages and leave everything else to native app silos.
immibis 11y ago
I guess by that reasoning desktop apps should go away too, and we should all run ChromeOS.

pjc50 11y ago

We need a viewport-size-agnostic graphical native sandbox that works on x86_64 and ARM, and can be reasonably sure is escape-proof. Which is hard to do if you let it have multitasking and access to graphics drivers. Then we need a means of letting it have just enough network access to be useful but not enough to exploit the rest of your system, bearing in mind the discussion of WebRTC going on at the moment.

dikaiosune 11y ago
Isn't this kind of what most browsers are currently doing?

adrusi 11y ago

The cross platform experience will never match the native experience. Think about on the desktop. The only cross platform apps that behave natively on Mac, Windows, GNOME (and derivatives) and KDE are apps tha have completely separate front-ends for every platform. Firefox is an ok example of this, although it in a way forms its own platform rather than integrating with its host, still it pulls it off better than other cross-platform apps. The Transmission bittorrent client is perhaps a better example, it has at least 4 mature front ends: gtk, qt, cli and os x. This is only feasible for a little free software project like Transmission because its UI is fairly simple, it has a list of torrents, a settings dialog and a properties panel. Most apps that try to be cross platform just use a UI toolkit that acts as a cross platform compatability layer. Qt, GTK, Swing, WxWidgets and Tk all fit the bill. The result is that the app doesn't look good or integrate especially deeply into any platform, except sometimes with the platform the the developers personally use. There are few exceptions to this rule. One is Sublime Text 2+ which is built on Qt. Without any customization, its theme looks OK, but doesn't match the design language of any platform, and its integration with its host platform is non-existant, everything happens within the sublime text window (no notifications or system tray/menubar widgets, no quick-view previews in Finder or Nautilus, etc). It's possible to improve integration by intstalling a custom theme which lets the user override a lot of the UI design, including the margins and padding, and plugins are written in python and can access a lot of host platform features. If you want a native experience, you have to write a native app. You can share your business logic by linking to the same C++ code or in the future maybe by using react native and sharing the same non-view code. But your UI-layer has to be tailored specifically to the host platform in order to look good.

dikaiosune 11y ago
Agree completely, what I'm seeing though is "web" being the new native for a whole lot of apps. It's familiar to users across platforms, it usually looks good, and while it might not integrate with the host environment, it provides many aspects of the native experience.
tonyarkles 11y ago
We have the same philosophy. Most of my experience here is with iOS and Android, but also a bit of Windows/Linux/Mac. If it's going to feel polished, then it's going to need a separate UI front-end for each platform. It's not that there's not yet a sufficiently good cross-platform library; it's that an Android app and an iOS app are different! They're structured differently! And if you try to use an x-platform library, you're going to end up with an iOS-app-that-runs-on-Android, or an Android-app-that-runs-on-iOS, or a this-app-doesn't-feel-right-anywhere. My approach varies based on the application, but in general one of two things end up happening: either the majority of the processing gets pushed onto a server with a well-defined REST API, or the processing gets put in a C++ library that gets linked everywhere (with JNI shims, ctypes shims, whatever's needed to load it in the appropriate environment). This approach does a few things: it ensures that you've got a UI that fits every platform, it improves code quality (you can't add a chunk of business logic in your view handler), and it makes porting so much easier.