though performance wise it would be worse, since progressive web-apps run on Javasript and native apps get to be written in much faster languages
I don’t know if progressive web apps are slower than native apps, but if they are, I doubt it’s because of the speed of the languages (“JavaScript used to be slow and weird, and now it’s fast and weird”)
Given that native mobile apps are often written in C, objective-C or C++, just on a simple language level you should expect something like 3-10x speedup from the switch from an interpreted language to a compiled language (sometimes more, sometimes less, depending on the application). In general interpreted languages continue to be substantially slower (and though interpreted languages have been getting faster due to smarter execution environments and lots of fancy tricks, so have compiled languages, due to improvements in compilers).
The comparison is pretty similar to the python vs. C comparison, which I have a good amount of concrete experience with, since it’s super common that if you write ML code, and want to optimize any specific part of it, you rewrite it in C or C++ and then call that C code from Python. Doing so usually gives you something like a 10x performance improvement, though it depends a bit on exactly what you are doing. I expect the difference between C++ and javascript to be similar.
So yes, I do think that progressive web-apps running on javascript does mean they are fundamentally slower than native apps written in C, C++, or even Swift or Java. This doesn’t mean it’s impossible to write a performant progressive web-app, but it does likely mean that you have to put a lot more thought into optimization than you would if you were to write native code (also because the javascript ecosystem really isn’t well-optimized for performance, and so it’s really easy to build a non-performant app).
I’m still not sold, but I think it’s pretty awesome you wrote this out in response to what is, ultimately, someone poking their nose into your internal high-context LW dev models
None of this actually matters in this kind of website/app though. Displaying text boxes doesn’t require very much code. The performance aspects will mostly involve memory usage, rendering speed, and efficient algorithms.
I agree with this hypothetically, but I actually think this matters a lot in practice. Browsers are actually just quite slow at doing a lot of things. As a concrete example, the Facebook web-app (which I use since I don’t want Facebook installed on my phone) is many times slower than their native app, with scrolling often being visibly sluggish, and clicking on buttons having a visible delay.
Of course it’s possible that the app is just written less well, but given that the same is true for the Twitter web-app, and the apps of basically any major platform that I have used both as a native app and on the web (Pinterest, Messenger, Google Plus in the old days, Adobe Color, Google Docs), I think it’s reasonable to conclude that native apps feel a lot snappier and are generally faster across the board, at least on my relatively weak phone CPU (My phone is about ~5 years old now, so it does tend to struggle with a reasonable number of websites). I think a substantial chunk of this is explained by the different languages, and another substantial chunk is probably the result of the different ecosystems, with the javascript ecosystem being generally not very performance friendly.
Again, I am not saying at all that it’s impossible, or even that hard, to make a performant web-app for something in the reference class of LessWrong. I am just saying that if you build an app and don’t make performance an explicit goal of your webapp, and don’t put substantial effort and design attention into it, then the difference between a native app and a webapp will be quite substantial. Of course if you do put in that attention and thought you can make it snappy in javascript. As you say, fundamentally you are just putting text in boxes and the theoretical limit of performance is far far above what you need for an app like this.
I don’t know if progressive web apps are slower than native apps, but if they are, I doubt it’s because of the speed of the languages (“JavaScript used to be slow and weird, and now it’s fast and weird”)
Given that native mobile apps are often written in C, objective-C or C++, just on a simple language level you should expect something like 3-10x speedup from the switch from an interpreted language to a compiled language (sometimes more, sometimes less, depending on the application). In general interpreted languages continue to be substantially slower (and though interpreted languages have been getting faster due to smarter execution environments and lots of fancy tricks, so have compiled languages, due to improvements in compilers).
The comparison is pretty similar to the python vs. C comparison, which I have a good amount of concrete experience with, since it’s super common that if you write ML code, and want to optimize any specific part of it, you rewrite it in C or C++ and then call that C code from Python. Doing so usually gives you something like a 10x performance improvement, though it depends a bit on exactly what you are doing. I expect the difference between C++ and javascript to be similar.
So yes, I do think that progressive web-apps running on javascript does mean they are fundamentally slower than native apps written in C, C++, or even Swift or Java. This doesn’t mean it’s impossible to write a performant progressive web-app, but it does likely mean that you have to put a lot more thought into optimization than you would if you were to write native code (also because the javascript ecosystem really isn’t well-optimized for performance, and so it’s really easy to build a non-performant app).
I’m still not sold, but I think it’s pretty awesome you wrote this out in response to what is, ultimately, someone poking their nose into your internal high-context LW dev models
None of this actually matters in this kind of website/app though. Displaying text boxes doesn’t require very much code. The performance aspects will mostly involve memory usage, rendering speed, and efficient algorithms.
I agree with this hypothetically, but I actually think this matters a lot in practice. Browsers are actually just quite slow at doing a lot of things. As a concrete example, the Facebook web-app (which I use since I don’t want Facebook installed on my phone) is many times slower than their native app, with scrolling often being visibly sluggish, and clicking on buttons having a visible delay.
Of course it’s possible that the app is just written less well, but given that the same is true for the Twitter web-app, and the apps of basically any major platform that I have used both as a native app and on the web (Pinterest, Messenger, Google Plus in the old days, Adobe Color, Google Docs), I think it’s reasonable to conclude that native apps feel a lot snappier and are generally faster across the board, at least on my relatively weak phone CPU (My phone is about ~5 years old now, so it does tend to struggle with a reasonable number of websites). I think a substantial chunk of this is explained by the different languages, and another substantial chunk is probably the result of the different ecosystems, with the javascript ecosystem being generally not very performance friendly.
Again, I am not saying at all that it’s impossible, or even that hard, to make a performant web-app for something in the reference class of LessWrong. I am just saying that if you build an app and don’t make performance an explicit goal of your webapp, and don’t put substantial effort and design attention into it, then the difference between a native app and a webapp will be quite substantial. Of course if you do put in that attention and thought you can make it snappy in javascript. As you say, fundamentally you are just putting text in boxes and the theoretical limit of performance is far far above what you need for an app like this.