Why isn't there a LessWrong App? Is a "blog-app" sustainable/useful for a community?

post by Osson4 · 2020-08-02T17:47:59.136Z · score: 5 (5 votes) · LW · GW · 9 comments

This is a question post.

Contents

  Answers
    14 gbear605
None
9 comments

I am a newbie lesswronger, so it might be an already asked question, but I can't find an answer in the FAQs. I also don't have any idea of how many resources are needed to support a blog-app, given an already developed site/community. I would be glad if someone could explain the issues/difficulties, and why the community never exploited this channel to acquire new users/better accessibility (I would love to have an app instead of using the browser to browse the site).

Answers

answer by gbear605 · 2020-08-03T00:15:12.679Z · score: 14 (9 votes) · LW(p) · GW(p)

I'm not part of the LessWrong developer team, but I am a software developer. Generally, a relatively complex app like this would at least require an developer or two working full time for a year, which would be a very significant up front investment, plus any new features would have to be developed for both platforms in the future. This is doubly true if you want both an iPhone and Android app and don't want to use one of the somewhat questionable cross-platform frameworks.

Given that the LW team is (presumably) budget constrained, this would mean that they wouldn't be able to work on anything new for the website during this time. In addition, the work would be completely different from designing the website, meaning that it might take extra time because the team would need to learn the relevant skills.

On top of all of those supply-side constraints, there's also the question of demand. I'm sure that the app would be useful for you and for others, but I simply doubt that there would be that many users. However, I do think that it would be a decent idea to poll active LWers and ask them about various potential future features, including an app, and if an app got significant support, then it might be worth prioritizing.

comment by habryka (habryka4) · 2020-08-03T00:29:59.054Z · score: 20 (9 votes) · LW(p) · GW(p)

This seems roughly right to me. We've tried reasonably hard (though we could definitely do better) to make the mobile version of the site work well enough to use it on phones, which I do think is important, but I don't feel like on the margin making a native app version is that valuable. In the long run I do hope that we can make LessWrong into a proper progressive web-app, which would allow users to read articles offline, access the site through their home-screen and generally treat it like an app (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).

There is also one additional consideration, which is that I am worried about making LessWrong the kind of thing that is primarily a phone app. I think by their nature phones are much worse for longform content, both reading and creating it, and I think a LessWrong that was predominantly used by people on their phones would be forced to have much shorter content, and correspondingly be a lot more like the rest of the internet in it's pressure to be short and snappy and as a result of that fail to be able to grapple with problems in any real depth. I would never write a full LessWrong post on my phone, and even notice that the comments that I write on my phone or Ipad tend to be lower quality, with fewer links to external resources, and less thought put into the formatting or content. It's also much harder to present a lot of information on a small phone screen, making certain types of intellectual labor quite difficult (as an example, if we were developing our tagging system primarily for a phone-driven audience, I think it would have to be quite a lot simple and lose a lot of functionality, or require a lot more design effort put into it, which then corresponds to us building fewer other things).

I do think it's likely that if things go well, we will eventually have an app, but these tradeoffs are why it hasn't been a priority till now, and probably won't be for a while longer.

comment by Pongo · 2020-08-03T07:29:06.722Z · score: 2 (2 votes) · LW(p) · GW(p)

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")

comment by habryka (habryka4) · 2020-08-03T08:06:14.434Z · score: 3 (3 votes) · LW(p) · GW(p)

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).

comment by Pongo · 2020-08-03T18:33:38.947Z · score: 1 (1 votes) · LW(p) · GW(p)

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

comment by korin43 · 2020-08-03T16:30:46.495Z · score: 1 (1 votes) · LW(p) · GW(p)

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.

comment by habryka (habryka4) · 2020-08-04T19:07:11.233Z · score: 4 (2 votes) · LW(p) · GW(p)

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.

comment by ChristianKl · 2020-08-03T10:19:19.261Z · score: 2 (1 votes) · LW(p) · GW(p)

This is doubly true if you want both an iPhone and Android app and don't want to use one of the somewhat questionable cross-platform frameworks.

While there are costs to using a cross-platform framework I don't think it's that questionable to just use Cordova as a wrapper for the website. 

9 comments

Comments sorted by top scores.

comment by crl826 · 2020-08-03T00:44:10.809Z · score: 17 (10 votes) · LW(p) · GW(p)
(I would love to have an app instead of using the browser to browse the site).

Just out of curiosity....why?

comment by Osson4 · 2020-08-06T16:11:22.405Z · score: 1 (1 votes) · LW(p) · GW(p)

I have all the latest downloaded apps and the ones I use most on my home screen and when I want to relax with the phone, I very often just pick the first app I see. I recently wanted to start engaging with the community a bit more and having the LW app "a single tap" away would have been great tricking myself into doing so. Also I feel that the browser isn't that great to browse this particular community (for reasons explained in other comments) and got curious about why there isn't an app for every forum, at least for attracting new users.

comment by Kenny · 2020-08-26T19:35:41.103Z · score: 3 (2 votes) · LW(p) · GW(p)

I think, for both iOS and Android devices, you can add a link to a web page as an 'app' icon.

Maybe a better focus is what you want to better "browse this particular community", independent of whether it's via web pages in a web browser or a (mobile device) 'app'.

comment by Dagon · 2020-08-03T17:01:35.636Z · score: 13 (4 votes) · LW(p) · GW(p)

[curmudgeon vote here]

I already hate LW's attempts to "help" with rollovers and overriden click behaviors, which make it difficult to open new tabs for content on Mobile. A dedicated app IMO would be far worse than the current app, named "Chrome".

I can imagine some benefit to some to having offline access with occasional sync, but I seriously doubt it's worth the multi-master/merge difficulties to allow posting, voting, or tracking of read-status on offline and online/browser simultaneously.

comment by habryka (habryka4) · 2020-08-04T18:59:30.850Z · score: 3 (2 votes) · LW(p) · GW(p)

And overriden click behaviors

Huh, do you have any concrete examples of this? I think almost all of our buttons that could be links, are indeed links, and if you notice anything that is a weird javascript link that takes you to a different page but you can't open in a new tab, please let us know. I would consider that a straightforward bug, since I also hate links that I can't open in new tabs.

comment by Dagon · 2020-08-04T19:28:57.726Z · score: 3 (2 votes) · LW(p) · GW(p)

Sure. Chrome on iOS (iPad mini), viewing https://www.lesswrong.com/allPosts [? · GW] .

problem 1: tap on a green comment count, to see new comments. comments expand, but ALSO article popover appears, obscuring half the screen, with no way to dismiss (except clicking on blank area, which may or may not exist in the view - most areas on the screen do things).

problem 2: long-press on an article. get menu that includes "open in new tab", but ALSO article popover that obscures other article titles I may want to open tabs for, with same problems as above.

comment by habryka (habryka4) · 2020-08-04T20:14:52.916Z · score: 3 (2 votes) · LW(p) · GW(p)

Ah, yeah. I agree that the popovers could use a lot of work on mobile. I was thinking you were referring to something else. In this case I agree with you and am reasonably annoyed at how we handle this myself.

comment by ChristianKl · 2020-08-03T10:20:40.375Z · score: 8 (5 votes) · LW(p) · GW(p)

Both aquiring new users and better accessibility aren't the most important concerns for LessWrong. The core goal of LessWrong development should be quality. If there high quality content then the right people find their way to LessWrong. 

comment by Osson4 · 2020-08-06T16:23:52.537Z · score: 1 (1 votes) · LW(p) · GW(p)

I already got this message from the FAQs, but thanks for making it clear. I think this can/should go on the FAQ page so other newbies like me can read it, but I guess now at least when you search in the site you can find a fast answer :)