10 ms·

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps

• xyzzy_plugh 9y ago
  Your comment scared me, but TFA doesn't say that: > We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. Where do you see that chrome apps are being discontinued? Otherwise this is FUD.
  • TimothyFitz 9y ago
    EOL for Chrome Apps outside of Chrome OS was announced in August 2016 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html?m=1 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
    • datguacdoh 9y ago
      But OP is specifically calling out how this hurts Chrome OS, but it doesn't seem to affect that platform, from what I can tell.
      • itp 9y ago
        One way it affects it is to reduce the overall market for Chrome apps, reducing the incentive to make an app in the first place.
        • deleted 9y ago
          [deleted]
        • ehsankia 9y ago
          Exactly. I doubt most of the ChromeApps that exist today were made for ChromeOS. They were made because it was an easy and straight forward way of making a webapp on the desktop. Now, as OP mentions, everyone is moving to Electron and NWJS, neither of which works directly on ChromeOS. The only upside I can see is that CrOS is soon going to support running Android Apps which may save it, but even then... Maybe they'll figure out a way to run Electron/NWJS apps on ChromeOS?
          • foota 9y ago
            Maybe Google is looking to run Android apps in chrome?
          • zurn 9y ago
            This might also motivate better support for running ChromeOS apps under standard Linux.
        • dmix 9y ago
          The massive ChromeOS market as compared to the Chrome extension app store?
      • rhizome 9y ago
        OP isn't calling out how it hurts CrOS, they're describing how it's the place that Chrome Apps are still available, and thus could have that functionality copied out of CrOS and rejiggered to (continue to) work in Linux.
    • DonHopkins 9y ago
      Better EOL than EOLAS. https://en.wikipedia.org/wiki/Eolas https://en.wikipedia.org/wiki/Eolas
  • deleted 9y ago
    [deleted]
  • angry_octet 9y ago
    Deprecating it in the browser will kill any developer ecosystem. No one will write Chrome Apps anymore.
  • clhodapp 9y ago
    It may take a bit longer before it is disabled everywhere, but I feel like the writing is pretty much on the wall for NaCl at this point; If you develop or depend on apps that leverage it (in any context), this should probably be a warning sign to start thinking about how to sever that dependency (even if it's not urgent).
• limeblack 9y ago
  Forgive me if I misunderstand but won't android apps work on Chrome OS devices well at least the newer ones anyways?
  • eeZi 9y ago
    But that's only Chrome OS. Chrome Apps were great because they worked on all (desktop) platforms.
• wcummings 9y ago
  Why are you using an SSH client in your web browser?
  • eeZi 9y ago
    Chrome OS has no native SSH client, but Google published a NaCL based SSH client: https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=de https://chrome.google.com/webstore/detail/secure-shell/pnhec... It's useful outside of Chrome OS if you have a security perimeter based on TLS with ACLs and auditing already in place and you want to use it for SSH as well: https://github.com/zyclonite/nassh-relay https://github.com/zyclonite/nassh-relay https://chromium.googlesource.com/chromiumos/platform/assets/+/863cae3e4a79e123d04f9ee0b34ca1f14faa38d9/chromeapps/nassh/doc/faq.txt https://chromium.googlesource.com/chromiumos/platform/assets... Google uses a similar setup internally.
    • wcummings 9y ago
      I wouldn't call it a "Linux Desktop" if you can't run a standard SSH client. Chrome OS is it's own beast.
      • eeZi 9y ago
        Agreed, the SSH client is a bit of an outlier since you have that natively. I still listed it for completeness, I do use it, after all.
      • puzzle 9y ago
        In some ways, and if everything aligns, ChromeOS is actually better: https://groups.google.com/a/chromium.org/d/msg/chromium-hterm/LuDVJ67Q4BE/wa8xHWjm4AcJ https://groups.google.com/a/chromium.org/d/msg/chromium-hter... But "if everything aligns" == "only if you're inside Google".
        • eeZi 9y ago
          Hah, that's a funny thread. I've heard that Google is using Chromebooks for engineers with production access. Makes a lot of sense sense since Chrome OS is much easier to secure than a normal Linux distribution.
• bpicolo 9y ago
  Postman recently released a Native App, fwiw
  • johns 9y ago
    It's based on Electron
    • favadi 9y ago
      Don't be surprise, people consider electron "native" today.
      • Veratyr 9y ago
        Some people and those people are arguably wrong. Electron is really just Chrome with a separate JS engine that can run native code if the developer chooses to do so. Personally I'd argue that the "nativeness" of an application depends on how much the developer actually uses that ability to run native code. If you just throw a bunch of standard webapp CSS, JS and HTML in a folder and wrap Chrome around it, it's no more "native" than any other webapp. If on the other hand you have a whole bunch of native code doing, for example, media editing and the HTML and such is just the frontend UI, I'd say sure, that's a native app.
• jlarocco 9y ago
  > It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure. It would be more accurate to say it was the best thing to happen to your use of Linux in a long time, and it looks like even that is only because you're trying to use a bunch of closed source, non-cross-platform stuff. I also disagree that it makes users less secure. The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app". There's no way would I trust a web based SSH client, for example.
  • rhizome 9y ago
    Your pique is noted, but as more anecdata I use Chrome Apps for Soundcloud and Mixcloud, where it's nice to have a Chrome window that won't collect tabs and have a recognizable icon. I have dozens of tabs open in each of several Chrome windows and it can be a pain to find the one I want. Insert complaint about not being able to switch to a tab from Chrome Task Manager.
    • eeZi 9y ago
      You can do that with regular web apps - just create a desktop shortcut in the Chrome menu ("More").
    • jlarocco 9y ago
      I was specifically disputing the claims that Chrome Apps are "one of the best things that happened to Linux desktops in a long time" and that they're noticeably more secure. Taking Soundcloud as an example, Clementine (and probably most media players) can stream it just fine. Having a Chrome App is nice, but it isn't providing anything that isn't already available. I'd even say the Chrome App is a step backwards, because with Clementine I don't need a separate app for every music service.
      • eeZi 9y ago
        Streaming means parsing a bunch of untrusted data. What if ffmpeg/gstreamer/Clementine has a security issue? It happened before. With a Chrome App, it sits in a (really strong) sandbox and would need to escape the sandbox first. With a native app, it's game over.
• na85 9y ago
  Have you tried simply avoiding Electron and the bloatware it encourages?
  • AgentME 9y ago
    Wasn't his post arguing in favor of Chrome apps over Electron? He'd prefer to keep using Chrome apps and avoid Electron.
• quickben 9y ago
  Add to that list: - unblockable advertising - stronger DRM - Bitcoin mining that regular user can't detect - etc.. It will be good and bad, but, more bad than good. We could choose not to run .exe .bat and the rest So far, webassbly doesn't look optional.
  • mintplant 9y ago
    > - unblockable advertising I don't see how this necessarily follows from WASM.
    • artursapek 9y ago
      Don't most ad blockers just rely on media queries on the DOM? I imagine there's a lot of ways to circumvent those techniques when you are rendering raw pixels with wasm.
      • bastawhiz 9y ago
        Those pixels still have to go somewhere in the DOM, and clicks on those pixels still need to be handled. Plus, there's nothing wasm can render that you can't render with uglified JS already.
        • artursapek 9y ago
          So I guess it's equivalent to rendering ads on a Canvas element?
    • drdaeman 9y ago
      WASM is aiming to be fast enough to actually be capable of running a rendering engine. No more DOM for adblockers to look at, the pages may finally become canvases. I just cannot see this not happening.
      • captainmuon 9y ago
        Right, but you can already do that. Serve the whole page as a SVG, or JPEG, or PDF. You can already embed ads inline. Or just plain serve them from your own server, calling them article.jpg instead of http:://ads.adcompany.com/advertisement.jpg . The reason people don't do this, is because ad companies want control. They want to know exactly how often the ads are served and they don't trust you to serve their ad all the time and to all customers. Also they want to rotate it quickly. Finally, they want to track people. So the solution is to use remote javascript. 99% of ads work this way, even mayor news sites don't sell their own ads anymore. In this scheme, you'd probably still have ads served from a third party server. And even if they obfuscated the domain name, you could still probably identify their blob and block it. So I'm not to worried about unblockable ads. But you're right, they will try, and I am worried about sites becoming unusable because they will emulate browsers using canvas, poorly.
• snakeanus 9y ago
  > It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure. I will disagree, you can install most of these from the official repository of your distribution, without the use of electron. They are also very secure if you run them as an unprivileged user.
  • mrout 9y ago
    If you run them as a different user from yourself, maybe, but who does that? The idea that software is secure if it only runs on your own user account is stupid IMO. I'd rather that software had access to everything on my computer EXCEPT my personal files.
    • mnm2 9y ago
      It's about restricting access: One is protecting others; The second is protection within your own realm. Both are needed (Unix was just like: At least don't touch the data / system that other users have)
  • Hydraulix989 9y ago
    Suppose your JS Chrome App is getting the plug yanked on it, what are your alternatives? 1.) Port it to Electron and keep nearly the same code base 2.) Rewrite the whole thing as a native app in such a language as C++ without the use of Electron You can't possibly tell me that most developers won't choose #1 instead of #2 in a heartbeat (the switching costs are orders of magnitude more for #2, for one thing). Which is not a Good Thing. And it's also very obvious that #2 isn't nearly as secure as #1, which runs in a sandbox and so does not have direct unchecked access to users' files like #2 does.
    • lukechilds 9y ago
      Unless I'm misunderstanding something, an Electron app also has direct unchecked access to users' files by using the Node.js 'fs' core module.
    • snakeanus 9y ago
• lloydjatkinson 9y ago
  > require a native app otherwise Oh, the tragedy /s
  • AgentME 9y ago
    I'm extremely hesitant about installing random non-sandboxed applications. A Chrome app comes sandboxed with well-defined permissions. It's rare for native apps outside of mobile to come sandboxed or be easy to sandbox.
• _pmf_ 9y ago
  Agreed. WebAssembly is not a replacement; the point was not to allow to write extensions in native language, the point was to have a mechanism for escaping the browser sandbox in a controlled way. Google could have allowed Chrome to be used as a cross-platform GUI library (THE cross platform GUI library), but left it to Electron (lagging behind and requiring distribution); think XUL runner. I don't see the sense in that. I'd absolutely love a modern XUL runner.
• developer2 9y ago
  At a minimum, Postman does not belong on that list. It has been the case for quite some time now that Postman's desktop app is a) better than the Chrome App, and b) recommended by the developer. Postman aside, I don't understand why anyone would want any of the apps you listed to be installed as a Chrome App. Why would someone want an SSH or TeamViewer client to be tied to their browser? You're installing an application either way; Chrome internalizing the process as an attempt to offer convenience is a strange idea. Chrome is a browser, not an operating system - let the OS do what it does best. Chrome Apps were an unnecessary and proprietary mess - a failed experiment I am happy to see dismissed.
• Vinnl 9y ago
  I always wonder what it is that these apps need that cannot be done as regular web apps, as the web platform has provided more and more controlled ways to break out of the browser sandbox. (This is not rethorical by the way.)
  • fpoling 9y ago
    PNaCl is (or should I use "was") not limited to HTTP and can use UDP/TCP directly. So things like SSH clients are possible.
  • hisyam 9y ago
    Some devs want to develop js apps without paying/maintaining a server.
    • Vinnl 9y ago
      Since they're just static files, that should be pretty easy to do :)
      • hisyam 9y ago
        Some js apps need to work with database. eg: I'd like to build an expense tracker with html/css/js/sqlite but I want it to be offline and the user can choose to save their db file in their dropbox/gdrive folder.
• amelius 9y ago
  > instead of one Chrome instance, I'm now running five which use more than one GB of RAM each Is that true? Executables and shared object files are supposed to share (code) memory. So what big data structures does Chrome use that it can share between tabs (which are processes) and that it can't share between different instances of Chrome?
  • _pmf_ 9y ago
    > Is that true? Executables and shared object files are supposed to share (code) memory. Different version - different DLLs
    • amelius 9y ago
      Ok, so it's a version management problem then.
• equalunique 9y ago
  This is bad news. Wasn't aware.