Please explain apps to this 20th century relic

In My Humble Opinion
21

This is an interesting way to make the distinction, and I think I can get behind it. It might also help clarify the modern situation for the “relic” who originally posted the question. :wink:

A program is something that does actual work, and usually lives on a big computer somewhere in the cloud. An app is a small console that lets you interact remotely with that program.

Formal technologists’ eyes might twitch at that, but as a broad generalization, it seems kind of useful to me. If you have the Facebook app, you have maybe a hundredth of a percent of the overall Facebook codebase operating on your device. The vast majority of what Facebook is actually doing lives elsewhere. (Yes, yes, I know, “Facebook” is definitely dozens if not hundreds of separate programs, and I know when you’re talking about something that vast, the boundaries that delineate “separate programs” become somewhat blurry anyway. Work with me here, the OP seemed to be looking for a simplified picture.) The app on your phone is just the display window for what’s being done elsewhere, with a bit of interactivity.

Edit to add: obviously, there are exceptions; there are mobile apps that do a fair amount of work by themselves, and directly reach into databases without the intermediate broker suggested by the simplified summary above. But for most of what we tap on in our day-to-day, it’s a pretty apt conceptual model.

22

That sounds almost tasteful, like “gastronomist” or “hair stylist”.

Definitely doesn’t apply here :wink: “Computer snake oil salesmen” more aptly describes the industry.

23

Going back to thin and thick client …

In a lot of ways the app model is about offloading work from the servers to the client. Thickening up the client. Yeah, a lot of magic still occurs in server-world to generate the raw info. But all the effort to handle presentation & interaction can be offloaded to the client.

Historically the later model browsers, say 2010 and later could do a lot of that, but a) badly and b) inconsistently. Maintaining a, say, Android app for your e-commerce business is a lot less difficult than making the same e-commerce functionality operate perfectly on every brand and model of browser that might be found on an Android device.

And will result in your servers working less hard per user interaction with the app than with the website. Such that more users can be handled for any given expenditure on server infrastructure.

Beyond that, doing the UI server-side is very bandwidth intensive. Just pushing the minimally necessary raw info back and forth consumes far less bandwidth. With the result that each user experiences snappier performance and the total cost of adequate network bandwidth server-side might be reduced to 1/10th or less of what would be necessary if the whole thing was done the old pre-app way.

24

OK, well, I suppose this is that part of the SDMB thread lifecycle where, having met clarity and finding it lacking, a topic can now be muddied by gleeful nuance instead :slight_smile:

The traditional thin client/thick client model is now often thought of as backend/frontend, with the backend being the traditionally heavier server and the frontend being the lightweight app that the user sees on their device. And that still makes sense for certain classes of apps, as pointed out by Cervaise… you simply could not store all of Facebook on a single phone. There’s too much data, and the connections between them are too complex for a single device to go through. Most phones would struggle to even hold a complete copy of Wikipedia. And LLM chatbots are even more recent example… those take giant data centers, possibly with their own nuclear power plants, to train and run. You generally can’t do that on your phone except as a nano-scale demo (you can run similar chatbots as an standalone app, but they will be much “dumber” than the cloud ones).

However, for other classes of apps, your phone is more than powerful enough, and perhaps even better suited than a heavy server.

A common example is graphics-heavy games: they generally run directly on your phone’s internal graphics processor. If it’s a single-player game, there is no backend server at all (or there is, it’s used for tracking and serving ads). Even if it’s a multiplayer game, some companies try to go cheap and make users connect to each other, instead of all to a central server. Doing so saves the company money on servers and bandwidth, but makes cheating easier, since the person who got chosen as the temporary “server” has full control over the other players’ games.

But even that situation isn’t so clear-cut. There are massively multiplayer games that do require extensive backend servers to coordinate the activities of the dozens, or sometimes thousands, of players in an area. There are also services that take a game app and run it in the cloud for you, then stream you the graphics back as a video… now THAT is a true thin client, and we have none other than the AI chip giant Nvidia to thank for that: GeForce Now.

Then there are the apps that truly just make the most sense primarily as a frontend app, without a heavy backend. Office apps (Word, Excel, etc.) are like that, along with the Adobe programs. There’s no reason they should’ve become been a cloud-based subscription service instead of regular desktop/phone apps, except that the companies realized they could make more money by holding you hostage with recurring payments.

Modern phones and web browsers are more than capable of running all of that in your device. Your average phone today is much more powerful than even the best desktop computer of the 90s and 2000s, and web browsers have also come a long way. There are now great iPad drawing apps that rival the best of what was once Adobe’s exclusive domain. On fancier models, you can use the built-in LIDAR sensor to scan a room and then an algorithm on the device (or sometimes in the cloud; depends on the particular app) will turn it into a 3D model you can walk through. There is a free web app Photoshop clone, Photopea.com, that runs entirely in your browser.

At an even more extreme end, web-based design apps like Figma.com not only run in the browser with heavy use of Javascript, they actually integrate assembly code into the frontend to improve its performance. A while ago, browsers started supporting sandboxed low-level machine code written in desktop programming languages running inside web apps — something even Java and ActiveX applets couldn’t quite do. So now you can write your heavy “thick client” in some other language, compile it, and then bundle it alongside your light frontend… but both still run on the device, with the frontend offloading heavier computations to the faster compiled code. So what on the surface is “just” a design app that lets you drag shapes and text boxes around is actually quite complex underneath, and the result of many thousands of hours of programming.

So… now thick clients are sometimes thin again, thin clients are thick again, size doesn’t matter, and you can run entire operating systems inside a web app that then loads a web browser to run a game in the cloud to send you the pixels to display. Got it? :sweat_smile:

I’m not really sure if any of this is an actual improvement over Gopher…

25

I was given the title ‘GIS Application Engineer’ Thanks Apple, I ONCE used one of your devices. Never again.

26

I thought nowadays programming was called coding.

27

Which is when I say, “I’ll live without seeing that,” and close the window. Ditto for Facebook. If I detect it’s a link to a Facebook page I don’t even bother clicking on it because a view-blocking, uncloseable pop-up wants me to log into my Facebook account to continue. I have an account but haven’t logged into it for years.

28

Some apps have very useful features that aren’t possible on a website. A couple that I know, and use frequently:

  1. The Bank of America app allows you to deposit checks using the phone’s camera. Probably all major bank apps do this now.
  2. The Walgreens app allows you to refill prescriptions by scanning the bar code, again using the camera.
  3. The Mobile Passport Control app gets you through US customs and border patrol quickly at most airports. Part of the process is, it requires you to take a picture of yourself upon arrival.
  4. Ticketmaster now uses a system where ticket bar codes change every 60 seconds, so you have to use the app to display them.
29

All of those are examples of things a web app could do too. The companies just choose to force you into an app for their benefit, not yours. Web apps can access the camera and scan (or show) barcodes with ease, and have been able to for many years.

For the most part, it’s only offline data storage and notifications that web apps can’t easily do.

30

I didn’t think a web app could access a camera, especially since I don’t have a camera on my PC.

31

Must be able to, as Google Meet works with video in the browser on my PC (with a webcam installed).

32

They can definitely access a camera if it’s there, like on most laptops. I use websites that do that every week. If you don’t have a camera attached, well, that’s harder :slight_smile: You can buy a webcam, of course. But anyway, that’s not a technical constraint. There are phones without cameras too, though rare.

Edit: Example barcode scanner that uses a webcam: QuaggaJS, an advanced barcode-reader written in JavaScript

33

I would consider “programming” to be a more general term that may encompass other elements of the lifecycle like design and testing, especially in smaller projects, whereas coding is literally “writing code”. But that’s just my view of it.

34

That’s what the fancy-pants companies like to call “engineering” :slight_smile: I hate this title inflation. Design and testing was always a part of coding/programming, even back when we didn’t need inflated terms for our egos…

Anyway, I digress. Big companies like to invent new terminology to justify the fifty redundant positions and to better hide all the political power-jockeying behind the bureaucracy.

35

This xkcd describes 90% of phone apps.

36

Since that brilliance was written a decade ago the app providers have smartened up and now nerf the mobile website so the app is the more capable version.

But you still can’t zoom. Bastards

37

Maybe I’m not following you here, but by swiping up into App Switcher, the Home Depot app and Lowes’ app are one tap away from each other and I can see both of their screens side by side at the same time.

But Google/Microsoft loves that idea because now a third party knows you want to buy a ceiling fan. Sort of an out of the frying pan, into the fire situation.

38

I assume you’re being at least slightly facetious. The formalisms of software development are not related to the size of the organization (or at least, they shouldn’t be) bur rather to the size of the project itself.

For a very small project, the design and testing phases may be very informal and done by the same person who does the coding. Needless and pretentious bureaucratic rigour imposed on such a project is stupid and counterproductive.

But for a large project, requirements analysis, functional design, system architecture, detailed design, coding, unit testing, system testing, implementation to production, and possibly process improvement review, are all distinct phases which, along with overall project management, are usually led by different teams in well-specified phases. The whole process is quite properly referred to as software engineering.

Successful large projects also encompass ancillary tasks like getting stakeholder buy-in during the requirements phase – I know “stakeholder buy-in” is perilously close to a biz-speak buzzword, but it simply means making sure that key players in the organization support your project mission, otherwise it may be doomed before it even begins. Competent project management is not easy.

39

During some of the time I worked for Sun we used a thin client model called a SunRay, which was awesome. With my company ID I could go to a conference room with my card, plug it into the SunRay already connected to a projector, and get the presentation I had set up on the SunRay in my office wthout fiddling around connecting up a laptop. And I could travel across the country and around the world without a company computer. We eventually went to laptops like everyone else, with a SunRay app on them, but it was great in the dark ages.

Phones have limited real estate, so while you can do stuff on a web browser on a phone much of a screen is taken up by irrelevant stuff. Apps can be customized for more screens with fewer things to do on each, which is much easier to use. I’m not sure how driving with Google Maps would work in a web browser. My pharmacy app does much of the work and gives me a barcode I can show to the pharmacist which lets me get on a shorter line.
I’m saying this as basically a PC person who only uses my phone when I have to. I’d much rather see my work on a monitor and have a decent keyboard. But sometimes phone apps are much better. I never put bank apps on my phone. I don’t want to take the risk of losing it.
And web apps can be just as evil as phone apps.

40

This last has me worried a bit. Through Ticketmaster I bought in early March a couple tickets to a Ringo Starr performance in September using my desktop. I looked for a way to print a hardcopy and found none. I messaged customer service and got the reply back, I can’t, without explaining why; I have to use the phone ap to bring it up.

I installed the ap, connected it to my account, and it brought up the tix okay. Being paranoid I’ve checked every couple weeks and last time, I could not log into the account, even by putting the credentials manually. Uninstalling and reinstalling the ap fixed that, but now I worry it’ll happen when I’m waiting in line with a 3G connection.