6 ms·

>I see no benefits to PWAs For games, sure, native is much better. But for any other app, which doesn't require a lot of rendering and simulation, PWAs are act

by adflux 5y ago

>I see no benefits to PWAs For games, sure, native is much better. But for any other app, which doesn't require a lot of rendering and simulation, PWAs are actually a great option. You can have one codebase for both platforms. Through the use of Cordova you can actually use native apis very easily. Also, using PWAS gives you access to the thousands of useful packages in the npm ecosystem. How about the tens of thousands of themes you can use to enhance your app? Or things like Vuetify or TailwindUI to quickly craft attractive UIs If you're not making an app which needs a lot of computational power I would say a PWA is a great option.

caslon 5y ago
That is kind of the exact opposite of the point I was making. Games would be fine as PWAs in theory: nobody expects video games to use few resources or to be power-efficient. Anything else isn't a good fit, because PWAs are ridiculously bloated for fundamental reasons even for basic applications.
- adflux 5y ago
  What do you mean by "ridiculously bloated"?
  - dmitriid 5y ago
    The very nature of HTML and CSS which are designed to display some text and maybe a few images make them ridiculously unsuited for literally anything else. You as much as glance at a web page, and it causes a repaint and reflow of the page. Everything else stems from that.
    - BackBlast 5y ago
      HTML+CSS is a layout system that has been refined and heavily used in many screen sizes for several decades now. Try to find an equivalent system that works from 4/8k down to 320px width in any native system. I mean, there ARE downsides to using web tech, but as a flexible layout system that can gracefully describe very large ranges of targets I have not found it's equal.
      - dmitriid 5y ago
        > Try to find an equivalent system that works from 4/8k down to 320px width in any native system. You probably mean literally every native system. Because it's not like native toolkits didn't exist on the same systems as HTML+CSS. > a flexible layout system that can There's significantly more that's required of UI than just layout. And HTML+CSS are horrendously bad for anything beyond a static page of text with images.
        BackBlast 5y ago
        You just keep repeating that claim and don't bother to present an argument. There are plenty of effective dynamic web pages that are not painful to create as a counter point to your claim. For layouts, I've used various toolkits including Qt, Java AWT and SWING, and Visual Basic way back when. Creating a GUI that scales gracefully on these, in my experience, is time consuming and highly difficult. Most everyone favors static layouts because of the challenges. Learning responsive design on a web page takes a bit of time but it has the tools to reasonably manage a variety of layouts on a wide range of screens. I would even accept an individual native system's layout manager as a counter argument of something that is at least competitive. It really isn't an easy problem.
        dmitriid 5y ago
        > You just keep repeating that claim and don't bother to present an argument. These facts are obvious to anyone who has seen anything else besides just HTML+CSS. Adding a simple box shadow on an element will trigger reflow in most browser engines [1] Efficiently animating anything that as much as breathes at layout is impossible. Efficiently displaying anything beyond a few hundred elements on a page? Equally impossible (and there are no virtual lists on the web). But the actual argument is this: given "the most advanced and powerful layout system in the world that has no parallels anywhere else, it's so unique", why is it that most CSS frameworks struggle to implement anything beyond the most basic of controls (buttons, links, may be tabs)? > Creating a GUI that scales gracefully on these, in my experience, is time consuming and highly difficult. Ah yes. "Scales". Because this is the area that only HTML and CSS have to deal with. Because, you know, resizing windows didn't ever exist since the earliest days of GUIs. However, being able to work at different sizes isn't what "scaling a GUI" means, or should mean. Desktop apps have been able to work at different sizes for close to 40 years now. [1] https://csstriggers.com/box-shadow https://csstriggers.com/box-shadow
  - caslon 5y ago
    Here's a good example! Open up this page in your web browser; not the site the thread is linking to, just the thread: https://news.ycombinator.com/item?id=27576937 https://news.ycombinator.com/item?id=27576937 Opening it up, fresh, it's taking 49.9MB of memory for me. For a tab I've had open for a while, of the same page, it's doing 60MB. And that's despite it not being a "web application": it's barely a web page! So here I am, doing exactly what everyone claims I should be doing, and using a web browser for my web content. And one of the most spartan sites on the internet, Hacker News, has mildly-active threads that take up 60MB of memory. For the tab. Not for the browser, for the individual tab. The best Electron application I've ever came across launched with 100MB of memory consumption and pegs a CPU core. That's not even getting into how nearly every single Electron application puts 150MB+ on your hard disk, because that in particular isn't incredibly relevant.
    - adflux 5y ago
      I (and I think most users) don't care about how much memory an individual webpage uses, as long as it feels fast. I'm sure there are many like you who want applications to be frugal with memory and cpu consumptions, but I think most users don't really give a damn.
      - pseudalopex 5y ago
        They care when the computer slows down and the battery drains faster.
      - caslon 5y ago
        I personally like having battery life and the ability to multitask. I don't think it's something that only non-technical users want, or even something particularly rare. Surely most users like their phones lasting longer on a single charge, given that's sort of the root of the discussion.
        411111111111111 5y ago
        Memory consumption of that level has no noticeable impact on battery life. There are bloated web apps that should be improved for sure, but they also exist with "native" languages. The issue has always been runtime computations, PWAs are perfomant if you keep them low. I wrote myself an ebook and webnovel reader PWA which tracks progress by pixels and percentage amongst other things. There is no noticeable difference between fbreader (native) and this angular app. I get the same amount of drain per hour as I repeatedly verified when I switched.
jbverschoor 5y ago
Yeah, that is until you don’t want a webpage as an app. Proper accessibility, controls, behaviors, memory usage. I can only applaud Apple. Please do that Cordova stuff on your own phone. There are enough frameworks that aren’t that bloated if you really don’t want to develop for a platform
- adflux 5y ago
  Proper accessibility, controls, behaviors, memory usage All things which you can implement in a pwa. Do you have any experience building native, hybrid or pwa apps?
FridgeSeal 5y ago
> But for any other app, which doesn't require a lot of rendering and simulation, PWAs are actually a great option. Slack and Spotify are both resource-hungry applications that would benefit immensely from being native applications. Yet we are stuck with the worlds laggiest IRC client and an application that you’re actually better off running in the browser so it doesn’t destroy your SSD (again).
- BackBlast 5y ago
  Electron is somewhat different than a PWA. They are not the same. Electron packages up its own browser and something akin to a node process along with your code. There is effectively no sandbox on Electron. Last I played with it the minimum bundle size is ~80MB, depending on the platform and feature set and it runs somewhat larger on disk after install. A PWA uses the existing browser on your device and must abide by the browser's sandbox and limitations. It's basically running as a page tab but skinned to look like a native application. For both Slack and Spotify, I would prefer a PWA over electron. They work fine within the sandbox and then it's simply smaller/faster and your browser, the one major dependency, updates separately. That's less bandwidth to keep everything up to date, less resources both on disk and in ram. Given you advocate using the browser for Spotify, it seems that you would prefer it to be a PWA as well. There are pros and cons to both approaches, but from a resource perspective, PWAs are potentially quite lean. The last PWA I published has a download footprint of about ~800k, uses ~3MB on disk, and ~30-50MB of ram when running, and ~1s load time on my phone. It's pretty much a big ball of javascript, light on pics or media other than the icon set - but runs an inventory system and allows some modest camera assist from the device. Contrast that to a React-Native application I produced of the same complexity at a previous employer, it was 30MB download, 50MB on disk, and even more ram, and 3 s load time on my phone. PWAs potentially open faster than similarly complex native app if the browser is already running and in memory - which is a common case.
  - FridgeSeal 5y ago
    > Given you advocate using the browser for Spotify, it seems that you would prefer it to be a PWA as well Ideally I’d like us to stop trying to force every single application into the browser when they don’t belong there. I prefer to use Spotify on web over the electron app only because it’s only marginally less-bad there, I’d prefer it more if it was a native application like Apple Music is because all my music is on disk anyways.

by adflux 5y ago

caslon 5y ago

That is kind of the exact opposite of the point I was making. Games would be fine as PWAs in theory: nobody expects video games to use few resources or to be power-efficient. Anything else isn't a good fit, because PWAs are ridiculously bloated for fundamental reasons even for basic applications.

adflux 5y ago
What do you mean by "ridiculously bloated"?
- dmitriid 5y ago
  The very nature of HTML and CSS which are designed to display some text and maybe a few images make them ridiculously unsuited for literally anything else. You as much as glance at a web page, and it causes a repaint and reflow of the page. Everything else stems from that.
  - BackBlast 5y ago
    HTML+CSS is a layout system that has been refined and heavily used in many screen sizes for several decades now. Try to find an equivalent system that works from 4/8k down to 320px width in any native system. I mean, there ARE downsides to using web tech, but as a flexible layout system that can gracefully describe very large ranges of targets I have not found it's equal.
    - dmitriid 5y ago
      > Try to find an equivalent system that works from 4/8k down to 320px width in any native system. You probably mean literally every native system. Because it's not like native toolkits didn't exist on the same systems as HTML+CSS. > a flexible layout system that can There's significantly more that's required of UI than just layout. And HTML+CSS are horrendously bad for anything beyond a static page of text with images.
      - BackBlast 5y ago
        You just keep repeating that claim and don't bother to present an argument. There are plenty of effective dynamic web pages that are not painful to create as a counter point to your claim. For layouts, I've used various toolkits including Qt, Java AWT and SWING, and Visual Basic way back when. Creating a GUI that scales gracefully on these, in my experience, is time consuming and highly difficult. Most everyone favors static layouts because of the challenges. Learning responsive design on a web page takes a bit of time but it has the tools to reasonably manage a variety of layouts on a wide range of screens. I would even accept an individual native system's layout manager as a counter argument of something that is at least competitive. It really isn't an easy problem.
        dmitriid 5y ago
        > You just keep repeating that claim and don't bother to present an argument. These facts are obvious to anyone who has seen anything else besides just HTML+CSS. Adding a simple box shadow on an element will trigger reflow in most browser engines [1] Efficiently animating anything that as much as breathes at layout is impossible. Efficiently displaying anything beyond a few hundred elements on a page? Equally impossible (and there are no virtual lists on the web). But the actual argument is this: given "the most advanced and powerful layout system in the world that has no parallels anywhere else, it's so unique", why is it that most CSS frameworks struggle to implement anything beyond the most basic of controls (buttons, links, may be tabs)? > Creating a GUI that scales gracefully on these, in my experience, is time consuming and highly difficult. Ah yes. "Scales". Because this is the area that only HTML and CSS have to deal with. Because, you know, resizing windows didn't ever exist since the earliest days of GUIs. However, being able to work at different sizes isn't what "scaling a GUI" means, or should mean. Desktop apps have been able to work at different sizes for close to 40 years now. [1] https://csstriggers.com/box-shadow https://csstriggers.com/box-shadow
- caslon 5y ago
  Here's a good example! Open up this page in your web browser; not the site the thread is linking to, just the thread: https://news.ycombinator.com/item?id=27576937 https://news.ycombinator.com/item?id=27576937 Opening it up, fresh, it's taking 49.9MB of memory for me. For a tab I've had open for a while, of the same page, it's doing 60MB. And that's despite it not being a "web application": it's barely a web page! So here I am, doing exactly what everyone claims I should be doing, and using a web browser for my web content. And one of the most spartan sites on the internet, Hacker News, has mildly-active threads that take up 60MB of memory. For the tab. Not for the browser, for the individual tab. The best Electron application I've ever came across launched with 100MB of memory consumption and pegs a CPU core. That's not even getting into how nearly every single Electron application puts 150MB+ on your hard disk, because that in particular isn't incredibly relevant.
  - adflux 5y ago
    I (and I think most users) don't care about how much memory an individual webpage uses, as long as it feels fast. I'm sure there are many like you who want applications to be frugal with memory and cpu consumptions, but I think most users don't really give a damn.
    - pseudalopex 5y ago
      They care when the computer slows down and the battery drains faster.
    - caslon 5y ago
      I personally like having battery life and the ability to multitask. I don't think it's something that only non-technical users want, or even something particularly rare. Surely most users like their phones lasting longer on a single charge, given that's sort of the root of the discussion.
      - 411111111111111 5y ago
        Memory consumption of that level has no noticeable impact on battery life. There are bloated web apps that should be improved for sure, but they also exist with "native" languages. The issue has always been runtime computations, PWAs are perfomant if you keep them low. I wrote myself an ebook and webnovel reader PWA which tracks progress by pixels and percentage amongst other things. There is no noticeable difference between fbreader (native) and this angular app. I get the same amount of drain per hour as I repeatedly verified when I switched.

jbverschoor 5y ago

Yeah, that is until you don’t want a webpage as an app. Proper accessibility, controls, behaviors, memory usage. I can only applaud Apple. Please do that Cordova stuff on your own phone. There are enough frameworks that aren’t that bloated if you really don’t want to develop for a platform

adflux 5y ago
Proper accessibility, controls, behaviors, memory usage All things which you can implement in a pwa. Do you have any experience building native, hybrid or pwa apps?

FridgeSeal 5y ago

> But for any other app, which doesn't require a lot of rendering and simulation, PWAs are actually a great option. Slack and Spotify are both resource-hungry applications that would benefit immensely from being native applications. Yet we are stuck with the worlds laggiest IRC client and an application that you’re actually better off running in the browser so it doesn’t destroy your SSD (again).

BackBlast 5y ago
Electron is somewhat different than a PWA. They are not the same. Electron packages up its own browser and something akin to a node process along with your code. There is effectively no sandbox on Electron. Last I played with it the minimum bundle size is ~80MB, depending on the platform and feature set and it runs somewhat larger on disk after install. A PWA uses the existing browser on your device and must abide by the browser's sandbox and limitations. It's basically running as a page tab but skinned to look like a native application. For both Slack and Spotify, I would prefer a PWA over electron. They work fine within the sandbox and then it's simply smaller/faster and your browser, the one major dependency, updates separately. That's less bandwidth to keep everything up to date, less resources both on disk and in ram. Given you advocate using the browser for Spotify, it seems that you would prefer it to be a PWA as well. There are pros and cons to both approaches, but from a resource perspective, PWAs are potentially quite lean. The last PWA I published has a download footprint of about ~800k, uses ~3MB on disk, and ~30-50MB of ram when running, and ~1s load time on my phone. It's pretty much a big ball of javascript, light on pics or media other than the icon set - but runs an inventory system and allows some modest camera assist from the device. Contrast that to a React-Native application I produced of the same complexity at a previous employer, it was 30MB download, 50MB on disk, and even more ram, and 3 s load time on my phone. PWAs potentially open faster than similarly complex native app if the browser is already running and in memory - which is a common case.
- FridgeSeal 5y ago
  > Given you advocate using the browser for Spotify, it seems that you would prefer it to be a PWA as well Ideally I’d like us to stop trying to force every single application into the browser when they don’t belong there. I prefer to use Spotify on web over the electron app only because it’s only marginally less-bad there, I’d prefer it more if it was a native application like Apple Music is because all my music is on disk anyways.