It bothers me that Google does not seem particularly interested in doing the one thing that would make their Android platform absolutely dominant: Allow Chrome to run Android apps on Mac and Windows.
Google has already done 90% of the necessary work by adding Android apps to ChromeOS. Two and a half years ago it created "App Runtime for Chrome" which demonstrated that Android apps could run on Windows and Mac in a limited, buggy way [1]. If Google had put meaningful effort into developing such a strategy we would by now have a relatively simple way to develop software which runs on 99% of laptops and 85% of smartphones and tablets. Developers would now be targeting 'Android first' instead of 'web app first then iOS then maybe Android'.
Sun tried that, back in the day. Maybe you heard about Java applets, maybe you didn't. They were the slowest thing about the web, insecure even with a sandbox, and just an overall pain. Short of having a jvm always running on your machine, the performance of Android-via-Chrome will completely turn people off the Android ecosystem.
IMHO, the history was different. Java applets were initially secure in a sandbox and faster than what was possible with the "javascript" of that era.
Applets have become slow to start many years latter when bloated "enterprise" applications have been produced in abusive ways.
The security of applets has started to deteriorate a bit slightly before the death of Sun. It has become a security hell only since it is in the hands of Oracle.
The startup time was horrible. The speed, once it was running, was good, but the startup time made it completely unusable on the web. The ugly default UIs in Java did not help.
I did my fair share of applets back in the day, starting with the very first public versions and have very vivid memories of the loading screen :)
You should also take into account that internet speeds of that era were not as great. Today, we download multiple megabytes of javascript. Back then downloading the same multiple megabytes of java was slow because of network.
I always wonder -- if Sun had forced people to build their own loading screen UI per applet -- how the perception of Java (and Java Applets) would be different.
I recall loading webpages in IE where the browser would completely stop for 30 seconds while the JVM fired up.
JavaScript at the time was mainly used for snow flakes on the web page or annoying mouse trails on the web page, as I recall. Oh, and maybe rollovers. I remember Microsoft pushing DHTML and seeing IE4 as a leap forward compared to IE3 but I do recall Java being slow. And slow.
The first is no longer an issue. They can just use a modern just in time compiler and it wont run slower than Java on Android. Chrome already has one to deal with JavaScript powered Web 2.0 applications.
The second was as far as I can tell an API issue. Applets would block everything by default until they were loaded. A really bad idea in a single threaded environment when you had to send several MB over low bandwidth and the JVM itself took long to start. Just making the load async with a completion callback could have solved this issue and I remember a few Applets that actually used an async download to reduce the hang.
You missed the biggest issue: "write once, mediocre everywhere." Windows, Mac, and X were all different, and Java Applets were necessarily bad at emulating all of them. While there are fewer Unices today, there are more GUIs, and cross-platform apps suck at least as much.
"Write once, mediocre everywhere" was a problem with Sun's implementation, not with the concept of cross platform code. There are tons of webapps which are very successful, despite being written 'once'.
In any case, Google doesn't need to be as strict as Sun was. It is free to implement "write 90% of your code once and 10% customised for each platform".
> There are tons of webapps which are very successful, despite being written 'once'.
Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues) and our expectations have lowered. How many of these web apps obey the native OS themeing for instance?
1) The fact that webapps can run relatively well strikes me as hopeful, considering how much more inefficient using HTML/CSS/JS is compared to Java applets. Or is the latter not the case (honest question)?
2) I'm not sure if our expectations have lowered much. Perhaps it's more that mobile interfaces are generally simpler and thus easier to make 'native enough'?
Although I think there's more going on in regards to 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native. And while it's certainly possible to make a web app just as shitty, if you rely on 'stock' html elements, a lot of the subtle native behavior carries over.
Just a few weeks ago, for example, I built a web-app for mobile devices. It felt off immediately because the scrolling didn't feel right. All I had to do was turn on the momentum scrolling (with a line of ios-specific css), and the scrolling suddenly felt native. Had I used a hypothetical Java applet equivalent, I might've had to either go for a non-native-feeling scroll or build it myself.
While I of course can't prove any of this, I think what people care about is that things feel native, not the 'skin' used to display it.
> 2) I'm not sure if our expectations have lowered much. Perhaps it's more that mobile interfaces are generally simpler and thus easier to make 'native enough'?
I think people finally called the bluff that users have any expectations. And even if they had, what they don't have is choice. The current market is that everyone is building a walled garden around their selling proposition, so if a company decides to make a web app instead of a native one, then that's all you have. Nobody will make a better one and risk getting sued. If a service doesn't want third party applications, then they won't happen.
As you note in your comment, if one sticks with default, "stock" elements in their web app, things look and behave OK on a given platform. But nobody does that, for some reason everyone has to screw this up with tons of CSS and JavaScript that make the whole thing maybe prettier, but also noticeably slower and without all the native idiosyncrasies.
> considering how much more inefficient using HTML/CSS/JS is compared to Java applets. Or is the latter not the case (honest question)?
It's a really interesting question actually because it's so hard to compare the two. On any objective measure, today's web apps are much better than applets in terms of responsiveness, etc. But then again, an applet could run on machines with 16MB of RAM total. I think you'd be hard pressed to get plain html page in a modern browser to run on a machine like that. Either way, in both cases we had a much better solution in native apps.
> 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native.
Modern web apps can score better here, but quite often they don't. The more complex the become the less native they get, scrolling, text input, etc are generally OK (unless your an arshole that overrides scroll behaviour), but html still doesn't have an equivalent for native table views and the goodies (navigation, resizing, performance) that comes with them.
For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
> Modern web apps can score better here, but quite often they don't. The more complex the become the less native they get, scrolling, text input, etc are generally OK (unless your an arshole that overrides scroll behaviour), but html still doesn't have an equivalent for native table views and the goodies (navigation, resizing, performance) that comes with them.
Oh yeah, complex UI stuff is definitely a good reason to avoid web apps.
But for many, probably even most apps it's precisely scrolling, text input, and other 'basic' stuff that matters, and in those cases a web app's 'default' will be more native.
> For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
I agree on a personal level, but I suspect we're outliers. Can't substantiate that at the moment though, so I might be wrong.
> How many of these web apps obey the native OS themeing for instance?
Forget the theme - how many of these web apps obey the native OS GUI features? TAB-navigation, arrow navigation (in e.g. lists), accelerator shortcuts, editing shortcuts, not to mention a lot of visual idiosyncrasies that together make the interface feel "right"? Ironically, if you use default HTML controls, most of the things will be OK on a decent browser. But no, designers and developers absolutely have to make it worse by applying tons of CSS and JavaScript.
This applies to web apps pretending to be mobile apps, too. You can quickly tell one from another; the web app is the one with mediocre UI that behaves "wrong" in more or less subtle ways.
> Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues)
If an issue no longer affects anyone in any way, is it still an "issue"? Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
> If an issue no longer affects anyone in any way, is it still an "issue"?
I said it was masked, not gone. It still causes a lot of issues for people on resource constrained machines.
> Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
For much of computing history where were making clear gains with newer hardware. Up to the 90's software was getting more bloated but it was doing more. Most apps today really aren't doing much/any more than we were doing in the 90's but require vastly more powerful machines.
The problem is not technical and never was, it's that Apple and Microsoft would do anything to maintain an 'application barrier' that makes genuine cross-platform coding as hard and inconvenient as possible. It's all about developer lock-in and control over the customer, even more today than it used to be in the 90s.
How would you caracterize Microsoft's open-sourcing of the .NET stack, support to run it on Windows and RHEL (actually support to run RHEL on Azure), VS code universal electron app, the whole Office 365 paradigm, and multiple apps like Remote?
It seems to me that the 'new' Microsoft (since Satya Nadella took leadership) is changing their closed/proprietary stance on many topics. Not everything of course, they still have to sell stuff, but as far as "genuine cross-platform" is concerned, they are certainly giving developers all the tools to both make and target all major operating system.
> How would you caracterize Microsoft's open-sourcing of the .NET stack
Giving anyone not on Windows a second rate experience? Core as the name says provides only a subset of the Windows .Net framework and most .Net code in the wild is written with the implicit assumption that it runs on the Windows framework.
> VS code universal electron app
Instead of making their main IDE a proof of concept for .Net Core they wrote a Web3.50/NodeJS IDE. I am very sensitive to high latency IDEs so that is something I wont ever touch.
> the whole Office 365 paradigm
Trying to keep up with the competition, Google Docs ring a bell?
> since Satya Nadella took leadership
Nadella 2014. Linux on Azure 2012. Office 365 2011. Mono based on Microsoft’s promise not to sue 2004. Open sourcing parts of .Net is really the only thing you can assign to Nadella, everything else was still done by the good old triple E leadership.
Webapps in the sense of "fancy JavaScript" are no better than Applets. Google has the infrastructure, money, and business model to put most of the code on their servers and write native clients. Modulo privacy issues, they have found a solution.
Oh I bet they are! Like, anything is better than those slow, buggy and annoying Java Applets and I'm so thankful to god they're over. Did anyone ever notice how slow they were not only to 'run', but to initiate and start doing just about anything. I always knew it was a java applet even before it started anything because of its characteristic loading behavior.
Webapps today are the same. Their characteristic behaviour is rendering the skeleton of their UI, and then greeting you with a spinner. They take about as much to start up as Java Applets did.
Now, consider the orders of magnitude improvement in computing power over the years, and notice that webapps aren't really doing anything more complicated than old applets did...
There is one BIG difference.
The Android frameworks are already the default on a major platform.
Googles Material Design already looks native on both Android (majority phone platform) and ChromeOS.
Java did not have a major platform where it was the default framework. It was not the default on Windows or Mac, not even on Unices (with the exception maybe of SunOS or Solaris, but not even there).
If Java framework was not the default anywhere, then the primary reason to use Java was because it works everywhere. The primary reason to use the Android frameworks and Material Design is to publish on Android. Having it work everywhere else is a great bonus.
Android and Material Design will not be "write once, mediocre everywhere". It may become "write once, great on Android (majority of phones) and ChromeOS, mediocre elsewhere." But writing for Android does not exclude creating native versions for other platforms. Using Java did exclude creating native versions because that was the reason to use Java, to not have to write native versions.
I thought it was "write once, test everywhere" because the ideal of cross-platform software forgot about developers doing system-specific things (eg. file system paths)
I never understood the need to "emulate" all of them. Linux has always been a mess of tools written against different UI styles ( GNOME, KDE, MOTIF, ... ), Microsoft also reinvents its UI with every release leading to outdated application UIs and I don't know how consistent Apple was. I think the best you can do is choose one and stick with it, its not like most websites look and feel native.
So were Java Applets with AWT. Users hated that, so Sun tried PLAF, a half-assed emulation of each platform. That didn't work either, so Applets died.
If Chrome manages to provide better versions of most applications on most platforms, it may win. Otherwise, people who use those applications will hate it with the heat of a thousand Suns, and it will go the way of the Java Applet.
> So were Java Applets with AWT. Users hated that, so Sun tried PLAF
Uh, Java AWT was the native toolkit. Swing was the non native UI with the ugly METAL default Look and Feel. There are some nice custom Look and Feel implementations that don't try to emulate a platform, I think Matlab uses one for its UI.
And the Metal plaf was the least ugly of the three that were originally shipped with JVM (other two tried to match how AWT would look on Windows and Unix). But IIRC, AWT was not native (in the sense of "calls native OS GUI components") but only tried to look native and failed horribly at achieving that.
One thing that strikes me as weird is that almost any widget set that does it's own drawing or even just it's own automatic layout and tries to match look and feel of native UI invariably does not match even the basic look because various UI components use wrong size, are placed slightly differently and so on. For example everything I've ever seen that tried to match how windows 3.1 Ctrl3D looked draws window decorations one pixel narrower than the original, which is plainly visible and ugly, similarly things that attempt "looking like Motif" usually use different thickness for various lines and borders and also often mix-up meaning of focus rectangle (which should move by tab) and bevel around default button (which should stay in the same place irrespective of which control has focus). I see no technical reason why either of these things cannot be done right, is there some legal reason for introducing such small differences, that are small, but big enough to be annoying?
> But IIRC, AWT was not native (in the sense of "calls native OS GUI components") but only tried to look native and failed horribly at achieving that.
A quick check of wikipedia backs my memory, the Java classes were just a thin wrapper around the native components. AWT was mostly bad because it was limited, it does not even have a Table.
> even the basic look because various UI components use wrong size, are placed slightly differently and so on.
The windows API does not come with a layout manager AFAIK. I vagualy remember setting every bit of relevant size/position data by hand last time I used it directly. Same could be done with AWT, so this is mostly likely caused by programmer lazyness.
The part about sizing being wrong was not that much about AWT (although IIRC it also has this problem, at least on Unix, where it looks decidedly non-motif) as about just about any non-native toolkit that tries to look native. Windows does not have layout manager, but has API for getting preferred sizes for various low-level UI parts (in Windows 3.1 small part of of this was even user configurable).
Oddly you see non-native toolkits these days for many apps, and users don't seem as bothered anymore, unless I am mistaken?
For example, look at Windows 10 and the mishmash of controls (are they flat? or do they have a bevel?) available from the control panel, settings app, old COM dialogs, MMC etc. etc.
What choice do we have? Everyone's doing their own walled garden, so it's not like I can go and find an alternative SaaS / operating system with same features but better UI...
> For example, look at Windows 10 and the mishmash of controls (are they flat? or do they have a bevel?) available from the control panel, settings app, old COM dialogs, MMC etc. etc.
One of the last straws for me was the built in mail app that had this awful background image. Too many flashbacks of shitty access apps.
So were Flash and JavaScript and I still don't fully trust either. It helps that blacklisting almost everything with NoScript actually speeds up 90% of the sites I visit.
Maybe you somehow haven't noticed that even mobile devices now are an order of magnitude faster than desktop computers were back in the days of applets. Desktop computers can run Java applications with no significant overhead.
Not totally. We support a number of java applets at work. The clients still take "way too long" to load and feel bloated. "Way too long" is a subjective measure based on the current hardware/OS. For a JVM to not feel slow it would have to speed up relative to itself...and I haven't seen them do that.
If it's specific apps, usually it is just bad coding. 'Enterprise Java' style coding where performance is not even tested for, let alone designed into the algorithms.
Usually culprits are things like downloading multiple data files in a single threaded block, or insanely deep object graphs with thousands of memory fetches per real operation.
That's not really anything to do with the technique (code in browsers) or the runtime (JVM) or even the programming language (Java) -- and everything to do with poor development.
They're not really enterprise apps. They're just betting odds displays. But I hear you on the criticism of enterprise software still. I just don't think it's the thing here.
They could still be enterprise apps. From what I've seen of them, they appear to be little more than what you'd get off espn if espn were 100% betting. My point is it's not the system that they use to sync up lines and whatever...I think.
No. I'm not saying terribly designed, lazily coded enterprise apps are ok, I'm saying if Java can be fast on a $200 mobile phone, it can be fast on a desktop.
Java did have an API for accessing and manipulating the DOM since (iirc) JDK1.4 -- org.w3c.dom and sub-packages. It was not at all well known or publicised, though.
I think the key difference is you get to that incrementally. You start by "making the monkey dance" on an otherwise-static page, and you can work your way up to rendering everything on a fully-programatically-controlled canvas, a little bit at a time. Forcing you to do everything yourself from the start as TCL (remember tklets?) and Java did makes the barrier to entry much higher.
It's fairly rare to have web UI's built with canvas and WebGL - usually because they need to do something that is impractical using the DOM. They'll still use the DOM for the more conventional parts of the UI.
I agree on all counts, but have to say that Java Webstart was cool, it was a pretty neat way of installing and running applications directly from the web. Maybe not very secure, though.
One problem I see with Google's ecosystem is that they've betted on the wrong horse - Java is a pain in the ass and Android's Java foundations are its second largest weakness. (The first one being the Google-Vendor relationship that makes all but the very latest Android devices unpatched and 100% insecure.)
> ... Short of having a jvm always running on your machine ...
This is basically how Dalvik/Zygote worked on actual Android.
From what I know, Chrome too uses always-running background processes even if you don't have a browser window open (for mainentance work and to improve startup times).
Phones and desktops are completely different form factors with different constraints. Running an Android app on Windows would be a horrible experience.
Now this is a reasonable objection. Small form factor touch screen interfaces just don't work the same way as mouse-based desktop interfaces with acres of space. Trying to use a phone UI on a desktop is heinous (as is pointed out above with Windows 10 as the example.)
I used to regularly remote into a windows box (GUI mode, classic desktop) from my phone. 2560x1440 pixels of 21st century glory. Believe me when I say you do not want to use a desktop UI on a phone either. No, pinch-zooming hasn't proved to be a sustainable workaround.
> I think editors more like acme and less like vim might rise up.
Acme, and anything like it, would be completely horrendous on a touch interface. I use it regularly (although I find that I prefer Sam).
Edit: Then again, I have touchscreeens on many of my laptops. I don't find them useful. With the exception of drawing art, I wouldn't miss them if they disappeared.
I'm no so sure about "anything like it". A pen for easily selecting text, a one-two-three finger tap and/or a wheel/secondary input might work with a similar interface to ACME?
What does acme do to help on touch screens? I while ago I toyed around creating a vim keyboard for android, instead of having a virtual keyboard popup it show commands/motions instead. I abandoned the idea, but if text edition on a touch screen ever becomes feasible then I think the virtual keyboard has to go.
Unlike emacs or vim, acme leverages the mouse/gui for powerful editing - and I believe (multi)touch screens have the potential to be better guis than than screen+mouse. For one thing mice generally utilise at most three fingers and one hand - and IMNHO while eg blender/photoshop combine mouse and keyboard - the combination is awkward and not very intuitive.
I think (but am far from certain) that acme is a more promising approach.
I'm not saying that the app would have exactly the same UI on a phone and a desktop computer - the developer is free to customise the UI for the device.
'Most' apps do not get used even once [1] so their user experience doesn't really matter.
Most popular apps are designed for both tablet and phone. The ones that haven't specifically been designed for tablet are usually basic things like Guitar Tuner or Flashlight which don't suffer much from having a phone layout on a tablet.
Sure, you will still sometimes encounter a crappy app which has a horrible user experience on your device - similar to web pages and webapps which assume you have a 24-inch display - but not often enough for users to avoid the platform.
You could argue that webpages were never meant to host the kind of rich experiences and workflows native applications are known for. We just made it that way through years and years of momentum.
Would android apps be a good fit for desktop? Most of them do not even work well on a tablet and I think they would scale very badly to even touchscreen laptops.
I doubt that most developers would do any effort to have their apps "responsive".
I wish I could run the Trello app on my touchscreen laptop, if only so I could drag cards to the top to archive them (for some reason the web UI doesn't offer that). I wish I could get Google's suggested pages there. And for a lot of Amazon's apps, the Windows version feels like an out-of-date port of the Android version where I'd be better off running the Android version.
I don't think we really need another locked down OS where the vendor will control everything.
The other issue I have is that I don't see Android apps as efficient way of getting my work done, applications that don't need to worry about the mobile form factor will most of the time offer a superior user experience.
You already have a 99% cross platform way to ship an app, you can create a web app.
This would have been the way to build Linux into the next great desktop platform. I dont think people mind a 1GB Chrome runtime if it opens up a billion apps for them.
I think apps can be handled well by both browser and mobile phones. Considering that ART runtime also JIT compiles the java code to native, performance should also not be a worry.
Google has Chromebooks securely locked down, down to the hardware crypto -- there may be (speculating) inherent security issues with running mobile apps in the browser when you can't lock down the external environment.
I worked with a company that was part of the beta for ARC Welder and it was a very experimental product experience. Things were hit or miss on chromebooks. Support from Google engineers was amazing though.
Android is already dominant on mobile. Desktop market is shrinking. "Running" doesn't correlate to a good experience. Google probably thinks about that stuff.
The fact that it is an android app doesn't really matter. Your question becomes essentially "why would I want to run any app on Mac?" which I think you can figure out the answer to.
The amount of additional code required to support Android apps on the Chrome browser would be far too great. No one wants to download a 500MB+ browser.
> The amount of additional code required to support Android apps on the Chrome browser would be far too great. No one wants to download a 500MB+ browser.
So, divide up by services, and download only the services needed by installed apps with the first app that needs them. Adds basically nothing to the browser install.
My Realtek sound drivers for PC were around 450 MB (!!!). Nvidia drivers are around 350 MB and update quite frequently. That's insane. And Chrome has great update mechanism.
It could make sense as an optional download if you do want Android support. But, Google would never increase the download size of their browser to that extent.
For people who've already committed to Chrome, it might just be a one-time annoyance. But the time when Chrome had an seeming lock on the top seat in the browser wars has come and gone. I can definitely see this hurting new adoption, which would rightly make Google nervous.
You're forgetting something: This will not work for iOS. Why develop something which excludes a big chunk of the cake? I'm happy Google is not going this way... Apple is doing already enough damage with exclusive features.
> This will not work for iOS. Why develop something which excludes a big chunk of the cake?
By that logic nobody should even create native Android apps today. You're saying that if Android apps could run on even more platforms it would somehow stop being worth it to create them because iOS is excluded? Makes absolutely zero sense.
I would also go even further and would say it makes in MOST cases no sense to develop a purely native app today. From a economic standpoint most native, one platform apps make no sense nowadays (also many people are unwilling to install more apps) unless you have deep enough pockets. I'm happy that Chrome embraces the web and pushes web application even further. I see really no benefit in running Android apps on my Mac (this results in mixed touchscreen, non touchscreen experience). So Chrome is pushing technology for this 80-90% of devices but it is not Android (with its touchscreen focus) and I'm really happy it is the web which I can use on more devices with different UX handling and without installing stuff.
Google has already done 90% of the necessary work by adding Android apps to ChromeOS. Two and a half years ago it created "App Runtime for Chrome" which demonstrated that Android apps could run on Windows and Mac in a limited, buggy way [1]. If Google had put meaningful effort into developing such a strategy we would by now have a relatively simple way to develop software which runs on 99% of laptops and 85% of smartphones and tablets. Developers would now be targeting 'Android first' instead of 'web app first then iOS then maybe Android'.
Sundar, if you're reading this - do it!
[1] https://arstechnica.com/gadgets/2014/09/hack-runs-android-ap...