All Programming Is Web Programming (2009)

> server down or no internet connection

A number of web sites work offline, ie google docs.

> if you want to program software that people use, it's using web technology or it's a video game or it's a tiny tiny niche.

Or it’s a mobile app (though that can overlap with both video game and tiny niche if you want to make an app that covers all three bases at once).

Definitely not a BS reason, at least for me. The less code I write, the less I have to work (in general). If I can reduce total effort, accomplish the goals for those who pay me, and still pull in good income, I'm happy.

If I get bored because I've been so efficient at making the people who pay me happy that I have bored free time, I'll use all that slack time I've buffered up to try something different or new without time pressures, otherwise, maybe I'll just go to the gym or for a walk.

I like programming, but I don't want me entire life to be nothing but programming. I don't know how some code 60+ hours a week every week. I did that when I was a kid and was mesmerized by the computing industry and wanted to know how things worked--I'm no longer mesmerized. The mysticism is gone and for me, it's just about solving interesting problems using computers that improve people's lives. The less code I have to write to survive, the more choice of direction I have in any additional desires to code. If you're doing theoretical CS work then by all means, pursue the mysticism, but that typically isn't in code, that's in developing foundational theory.

I don't want interesting problems in my code if it can be avoided, I want my code to help with interesting problems in the real world. Interesting problems in my code means I have complexity to deal with and makes my software more prone to issues, difficulty maintaining, difficulty adapting. The simpler the solution where feasible, the better.

Some roles don't give you this sort of flexibility to make sure you're not bored and in those roles, that's where you see these elaborate overly complicated systems where people tuck things into the deliverables when they're unneeded. To me, that's a management and/or structural problem. I don't think my desires are all too different than most peoples desires, no matter what people in professional environments say to make sure they still get paid and are professionally progressing.

> A well done CRUD app should be pretty simple

Should it?

I'm currently building a "simple" CRUD app as a side-project. My background is in game development and backend, and I decided to learn React and React Native in the process. But at one point I realised that I want to app to be functional while the user doesn't have internet and sync afterwards, and now I'm in hell.

Now, I have to make all post requests idempotent, cache them on the client in case there's no internet, serialise and deserialise this cache when app quits and turns back on, display optimistic updates on the client as well but at the same time make it transparent in UI that those updates were not yet synced on the server, and handle request queue in such a way that when I send two requests that modify the same client-server object response to the first request that comes after optimistic update from second request doesn't override it, but a failure of one of the requests cancels all subsequent ones. I think I just got a headache writing that sentence. I also need invalidate local client cache of different server objects based on what mutation did I attempt to do and what result did I get from the server — when you create an object of some kind, different collections of these objects are invalid now, some can be updated optimistically, some need to be refetched. And I also need to invalidate these caches based on different kinds of errors returned from the server: authorisation, authentication, network problems, invalid user input and unknown problems that probably signify errors in my code all need to be handled differently.

May be I'm missing something, but implementing all of that functionality properly still seems like an unsolved problem out of the box. I've already prototyped solutions using useSWR, React Query and Redux, and I'm still not satisfied, as not of all these cases are handled properly. However, now I understand why so many web and mobile apps have so many bugs: based on the state of the tools and libraries, it seems that most developers simply don't care for all these cases and mostly stay on the happy path, cutting their workload by the factor of 10.

> One size fits all was, is, and will never be true. Are there certain applications that benefit from being web applications? Sure. But is this a panacea? Certainly not.

Agreed, well-put.

Technologist and decision-makers have a tendency to gravitate to one way of doing things (the way they know how) and then advocate that their way is the "one true way" to solve all problems.

Rather, there are a lot of tools to solve todays tech and business problems. Best to let the use case drive the choice of tech (ie, web app versus native).