> Performance of modern web apps is simply awful compared to their native counterparts
> There aren't any hard technical problems there - we obviously manage it on the web, so its easily possible
"easily?" Didn't you just say we're managing it badly on the web?
It turns out that it's quite difficult to develop an app-like experience that loads from scratch on a cellular connection and is ready for the user to interact in just seconds. The app folks will have it just as bad, if not worse, because they've got no practice.
* it assumes you're online
* features can be removed at any time even if the user relies on them
* link rot
* totally unsuited for sensitive data
Instead solving this problem will 'just' require tons of work. We need to improve our compilation toolchains to allow native apps to load progressively. We'll need better ways to monitor and analyse application size & performance. We'll need new libraries and we'll need buy in from vendors. And as thats going on we need to convince developers to actually care about this stuff. Again, all these problems have been solved for the web. We 'just' need to backport all that stuff to native apps.
No question there's lots of work to do. But its all (obviously) solvable with code.
The filesize may be a little bigger than native apps, and redundant if you install more than one of such apps, but in this day and age of high bandwidth and storage that's an acceptable tradeoff. I spent 2015 working on a Win/Mac/Linux app where this would have been the preferred solution, it was annoying that in 2016 it still doesn't exist and as a result we're getting janky Node.js-based platforms like Electron (http://electron.atom.io/) instead.
Qt and GTK are the only mature enough x-platform non-web-based options it seems, but Qt is not open source and GTK's look is dated.
Not only is Qt open source, it is also free software according to FSF. Core Qt and most modules are released under the LGPL, the rest under the GPL.
Qt even has a binding poison-pill promise that will make the code BSD-licensed should Qt (the company) stop releasing it. See https://www.kde.org/community/whatiskde/Software_License_Agr... and https://www.kde.org/community/whatiskde/kdefreeqtfoundation....
I've worked with a team who develops a windows app which still uses QT4. They cannot migrate to QT5 since it requires a commercial license.
Still, LGPL libraries can be used for commercial software, this is a rather common use case.
https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
(Disclaimer: I work for Oracle but I don't speak for them)
(I can't comment on whether it is supported well since I've never used that part of NetBeans.)
Eclipse was apparently working on support for it at one point, but it looks to me like the work has stalled (just my impression from their bug database, I don't really know):
Since Java 8, the JDK offers tooling to package applications, making it standard the way many third party bundlers used to work.
In Java 9 there is a linker, which will allow for an application personalised JRE, coupled with the startup code.
The biggest problem was that using Swing properly required a mix of programming and designer skills, which most didn't bother to learn.
At least on enterprise space of our customer base, we are still on Java and .NET for native applications, no Electron on sight.
What about JavaFX 1/2? Do you have any information about its popularity and usefulness?
It is the Java version of XAML, and it is quite nice to use, but the uptake has been on the slow side. There were quite a few sessions at JavaONE 2016:
https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event...
Probably the place where it has seen more uptake has been in car infotainment systems, like by Volkswagen.
https://static.rainfocus.com/oracle/oow16/sess/1462531766187...
However our Java desktop native projects are still mostly Swing based, or make use of either Eclipse or Netbeans as desktop framework.
And of course there is the Android Java fork, which doesn't offer any JavaFX compatibility (some guys on the community are porting it though).
Customers don't install apps for the most part. Why try to solve for that?
How many more lines of code do you think it'll take for chrome to feel fast and light again? Is it possible to achieve that by adding code, forever? And then to work around all the cruft in browsers we have frameworks like react - conceptually beautiful but which do layout by diffing thousands of DOM elements through javascript.
The stack is a mess, and I don't see any direction it can possibly go but fatter, bigger and uglier than ever before. Forever. Surprisingly, this is a fate native apps have avoided. And in avoiding that fate new laptops have amazing battery life and work great. Well, until you open chrome or slack that is.
> Customers don't install apps for the most part. Why try to solve for that?
I don't write code for customers. I do it because as a kid I fell in love with the craft. I just... didn't fall in love with programming for this. Nope nope nope I want off the train before I throw up.
The web has solved these things: it's an open standard which any serious device maker must support to be taken seriously. It can load applications in a relatively safe sandbox on demand. And it does all this with tremendous backwards compatibility that even 90s Microsoft would be envious of.
You're absolutely right Chrome is a virtualized operating system, but that's what it takes to be open and cross platform. Designing a better platform is the easy part; getting it to cross the chasm where it has first class device vendor support on a majority of platforms is the practically insurmountable part. I'm not saying it can't happen, but I don't think any organized group of humans has the power to do it intentionally.
Chrome is not a virtualized OS, it has become a mega-plugin similar to Java or Flash, except with better but still insufficient security. As more of the platform services are exposed to the internet, we'll start seeing new and interesting exploits, such as tracking users based on battery status and attacks on the local network (https://news.ycombinator.com/item?id=12406310).
Yes, the stack is a mess! I am hopeful that Web Assembly will make things better.
And the worst thing is that it is a hermetically sealed abstraction. There is no escape hatch to access the underlying primitives in those cases where you need them. Even virtual machines offer device passthrough these days for those cases where the virtualization overhead is too expensive and you need exclusive, direct access to some hardware. You could even assign the device to a container inside the VM.
Browsers offer no such way to punch through all the abstraction layers.
They don't even speak berkeley sockets.
For what is worth I can now only access FB from my phone using the browser (the web-app, so to speak), the native FB app has become ridiculously slow for quite some time. I use the native app only for uploading photos, once every 3 or 4 months. I'm using an iPhone 4 of which I'm still pretty happy, don't feel the need to drop 600+ euros on a New phone just yet if this one still does its job.
I'm guessing that link will crash on mobile, it slows down chrome on a desktop.
This will be fixed once web apps get more capabilities, don't worry, the entire web development community (except the josephg fellow above) is praying for it.
Since I returned back to native apps development, couldn't be happier, instead of having to deal daily with the crap and hacks on top of hacks, to make a stack designed for interactive documents work as a virtual machine.
I never see any web app one mobile feel good. But you never know.
also, with kotlin and swift doing native app is not that complicated. Learning a new API on top of native API I don't think is safe.
Also, google, apple they can change the rules and parts of the apps don't work anymore for x reason.
About #1. I am not that convinced that they are easier to build. Well they are, but building them in a way that fits each platform and performs well looks harder than making 2 apps.
I should mention that I work in a 30 devs teams (half iOS, half Android) working on the same in-house app.
I do believe that there is some potential to reduce duplicated work with something like j2objc. It is probably not the definitive expression of this concept, but it seems to me that it should be possible to share a lot of the business logic and this is what this tool aims to do. Some of the data objects should be shareable as well.
All the rest : UI, integrating with the Home screen, notifications, services, et cetera is just very specific to the platform and IMO should be written specifically for each platform.
I am still waiting for the perfect kotlin-to-swift library allowing that.
<Button android:id="@+id/button"
<button>They are slow because HTML rendering engines are slow, they are slow because Javascript engines aren't that fast compared to Java, C or Swift. Native frameworks don't need to deal with the complexity of an HTML layout and CSS. And native applications can be optimized to use way less memory than web apps. There is very little room for performance tuning in a web app, since it depends on the browser engine. Something good for a browser can degrade performances in another browser.
> <Button android:id="@+id/button">
Isn't dynamic, it is inflated once and turned in a class instance.
> <button>
Is highly dynamic as it can be replaced by anything at any time in an HTML page.
JavaScript can certainly deal with handling user input faster than the user can perceive, rendering engines can 'inflate' html (cache the layer tree) of dom that hasnt been invalidated.
While a commercial failure I worked on Firefox OS and we built an OS and application suite that on low end hardware compared often favorably than the equivalent on Android. The web does not need to be slower than native applications it just needs to be built better
I haven't heard this before. I assumed firefox os failed because the web stack proved to be too crufty for the low end hardware. Are you aware of any resources that go into more detail?
When we started it was an open question whether we could build a fast enough platform to compete with native applications, thats no longer a question I think about.
People think the web is slow because opening facebook.com takes >200 requests loading >4MB over the network of which a large chunk blocks any rendering (and all of which interferes with it). Build a web application which loads its UI from disk, caches application data, only touches the network for updates, does not block rendering waiting on bundles of JavaScript and uses proper practices for JS / dom manipulation (use transforms over animating top/left, dont attach process heavy scroll handlers) and your web app will be as fast as a native app
What is stopping a progressive web-app from performing as well, or nearly as well (to be impercetible).
I would have assumed that most of the time waiting is on network events - so using things like service workers to handle things asynchronously, and also handle caching would reduce things.
I watched a presentation on how Google made the IO 2016 webapp (https://events.google.com/io2016/):
https://www.youtube.com/watch?v=__KvYxcIIm8
and they used quite a few clever tricks to tweak performance.
Direct access to graphics, direct access to network, and direct access to storage.
The problem is that direct access to network and storage are ALSO security hazards.
Native apps are fast and enjoy every feature the OS has to offer.
Web apps are a pile of hacks that require conferences sharing clever tricks, usually browser specific, to make them usable at all.
Web apps only have two benefits over native apps:
1. They're easier to build in a cross-platform way, because you just have to make the app once
2. Users don't need to install anything
I hope in the long run we solve both of those problems for native apps and move back to writing applications which don't depend on a DOM implementation to run. React-native is a great step toward solving (1). I hope that in time we can have modern (reactish), good looking cross-platform toolkit for native app development.
But the biggest hurdle is (2), which very few people are attacking. App stores have helped a lot, but we need to be able to run native apps without installing anything. It should be as easy as it is on the web. Unfortunately native app authors usually assume all their assets are bundled. Nobody even thinks about how long it takes from the point when a user decides to install an app to when they see the first content. On the web we count that time in milliseconds and on native apps we count minutes. There aren't any hard technical problems there - we obviously manage it on the web, so its easily possible. We need native apps to catch up if they are ever going to be able to compete as a platform.