All Programming Is Web Programming (2009)(blog.codinghorror.com) |
All Programming Is Web Programming (2009)(blog.codinghorror.com) |
Everything else is worse because you are forced to use this single technology stack that the browser offers you. And people are trying to break free of those limitations, WebAssembly, WebUSB, or doing their own rendering into a canvas instead of having a DOM. 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.
At some point you browser will just turn into another operating system running on top of your operating system. The success of the current situation is, I think, mostly due to the fact that the web browser was a universally adopted least common denominator for running arbitrary code. You could get all the benefits of web applications without the browser, you could have platform independent binaries, you could download them on demand, you could sandbox them. But you probably would have a hard time to invent those standards and get them universally adopted by all platforms and operating systems.
Yes, all of that is true, and arguably none of it matters anymore.
> At some point you browser will just turn into another operating system running on top of your operating system.
That happened long ago, aside from a few specialized apps in mobile stores. The only time people need those is if they want faster repeat functionality that they use often (email, calendar, some stores, etc.). Otherwise, everything from office work to realtime raytraced gaming can happen in a web browser... and that's great, even if the dev experience relatively sucks and the code is messy.
The Web has turned programming from snobby/precise/beautiful/elitist/expensive engineering to arts & crafts and democratized content creation in the process (eh, for better or worse). Nowadays writing a webpage is easier than writing a letter.
Service Workers https://developers.google.com/web/fundamentals/primers/servi...
Why is that good? This is what people keep saying, but now instead of having Windows, Mac OS X, and a few Linux distributions, we know have several different browsers (Chrome, Safari, Edge, Firefox, etc.) running on top of several different OSs. The surface for error and behavior differences is much greater and the browser "OSs" are still inferior to the base OS. A desktop app gives me files I can manipulate and pass around, ability to use things offline, multiple windows, etc.
To do real work, I almost exclusively still use desktop (non-Electron) applications, where the web is mainly used for searching things, reading documentation, e-mail, and the like. I can't imagine working everyday inside a webapp. The main Electron app I use is Visual Studio Code, and it is held back being a desktop web app, namely due to an inability to have multiple windows within a single app.
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).
Nowadays making calls to the browser API is hardly any different from making system calls, and provides about as much generality independent of the actual operating system. Might just be my new showing but I don't think I remember it being any other way.
A number of web sites work offline, ie google docs.
I am surprised that high quality web apps still seem just as rare in 2021 as they did in 2009 despite the explosion of tools. i.e. apps that do something non-trivial, where the network usage disappears under "acceptable interaction time", where the UI toolkit is consistent & discoverable, where nothing is broken.
But it's still true - 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.
> Think only about the embedded programming… do you really think that you can create a web app to control your washer?
> Or do you want a web interface to drive your car?!?
> Get out of your cubicle and look around… you’ll see that there is something else running outside your server and browser.
> By the way, are you planning to create a web app for the BIOS of your computer?
Yes, to all :D
Those comments are golden.
Yes, your washer now has a web app to control it. But the embedded system that actually controls your washer is not a web app - not even close. Ditto with the computers in your car, or the BIOS in your computer.
"Oh, you think you could adequately program a neural interface using Scratch? How quaint"
https://news.ycombinator.com/item?id=27486041
https://news.ycombinator.com/item?id=27450431
It doesn’t matter because such comparisons are bullshit posturing by people who are insecurely qualifying their ignorance of how their beloved tools work.
A much less hostile statement that is easier to defend would be "All Programming is Network Programming" - could do an interesting syntax comparison based on what kind of network is in question, but I guess people do that all the time with "monads in other programming languages (than haskell)" kind of posts.
Computing would be immensely dull if we all fixated on our choice of platform to this extent. Platforms and languages are ephemeral and should be treated as such. The web will not always be the dominant platform.
What would people appreciate? A native client for Slack.
The OP that Jeff is commenting on isn't wrong. I see it everyday with junior devs that have very little practical experience with real engineering but they know a little python, maybe a javascript framework and can figure out AWS well enough to deploy it all using serverless.
This has been going on in multiple tech stacks - not just desktop programming. There was a time, for example, when people didn't use ORMs or nosql. Working with a real database is becoming a lost skill. One of the dirty secrets of the success of nosql is frankly because new developers are just bad at databases and don't understand fundamental skills. Ditto for AWS and application architecture.
I see it as somewhat inevitable that the next gen of developers want to do easier development. The logical conclusion of this will be 'point and click' (LCARS from Star Trek?). 30 years from now we'll be complaining that our kids dont know the 'complexities' of python/javascript development and do nothing but 'low code' development.
Point and click coding will never replace actually typing. Think about how much you can express with your hands versus speech. Unless you're versed in sign language, the gap will be very big.
It could be that "web programmers" are not smart enough to understand all of what was listed. It could also be that the listed stuff does not actually matter, as it's just one way of doing things. I don't think that having a job that is difficult to do is something that you should wear as a badge of honor, if it can be done in an easier way. The important thing is what you're able to do with the skills and tools you do have, and how much the people that use it like it.
The cynic in me thinks some people spend a long time to understand difficult things and concepts, and therefore don't want to let them go because it will effectively mean that they'd wasted their time.
Concurrency - web workers
Compilers - technically you can write compiler, but it's a very specific use case and I think that web is simply not a proper platform for writing them usually
3d - webgl
Class inheritance - classes in js (they're not identical to i.e. Java classes but they provide a very similar abstraction on the first glance)
Abstract classes - Typescript has it
Pass by value vs pass by reference - something that js programmers had to always understand in the past for the sake of handling primitives and objects in js
Garbage collection - weak references in js
Software development methodologies depend highly on team
Noob question. Aren't primitives immutable? Does it need distinguishing between Value & ref types?
function(x) { x += 1; }
function(o) { o.x += 1; }
Under the hood the `Number` x may have been passed by reference and changed by creating a copy, or it may have been JITed to be an i32 actually passed by value, or optimized out of existence entirely. How it is actually passed ends up being an implementation detail that you can't observe from high-level perspective.
I guess that the simpliest explanation would be by code:
let x = 4
let z = x
z = w
// x is still 4
let x = { b: 3 }
let z = x
z.b = 2
// x is { b: 2 }, because x and z hold reference to the same object
JavaScript has pride of place in browsers for now. But as WebAssembly gains traction, I look forward to avoiding the ungainly JS syntax in favor of pretty much anything else.
This may have more to do with the async nature thereof than the syntax specifics.
I am no web developer either, but know enough that web projects can be as complicated as any other type of software.
The basics are also good to know for any programmer, since web interfaces are a common and universal solution.
I've yet to use a webapp that I found truly inspiring in execution and design. I may just be a snob. It's possible, but most of the time it always feels like once you're starting to settle in and really use a webapp, the seams show themselves somehow: the browser hiccups, a server is slow, the React filler boxes linger for just too long. However, this doesn't really matter; the real goal of webapps is mostly to generate economic activity.
In the past, this caused me some existential grief. I deal with it by simply avoiding any dev work related to the web. For my own projects, I stick to native apps. I think it says something when I choose putting up with Xcode vs developing for the web. :)
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).
But that's boring. I'm a software developer, I want to write code. If my code is too easy, if it's just what it's supposed to do, where's the challenge? I know, let's use a difficult language! I know, I'll take this chunk, this is now mine, I call it a microservice and it's my baby. An overview of the whole architecture? Pfft that's boring. Netflix does it like this, look they have over a hundred microservices, clearly they must be doing something right, right?
I am a software engineer. My job is to solve problems, not to "write code". It just happens that most of the solutions will involve code. The less code that can be written to solve a problem the better. More code is a liability not an asset.
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.
Have a look at the Django tutorial, and see what you can produce with the Admin interface. It is a while lot less pain that what you are doing just now.
And that's even if you have a web interface. There's plenty of embedded systems where you don't.
Here's an embedded system that run on a spin of an 8051 with some extra on-chip peripherals. (Why? Because lower hardware cost.) It's never going to support a web interface.
Over there, there's an embedded system that controls the wing surfaces on a jet fighter. It has to adjust the wing surfaces every 1/40 of a second. A web interface will never be allowed anywhere near that.
And so on.
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.
Unfortunately not all managers agree on that point,
Reminds me of the "P" in Progressive Enhancement: https://blog.tomayac.com/2020/01/23/progressive-enhancement-...
There are many valid reasons to support the full "PWA experience" and have fallbacks that works without JavaScript, and it is attainable. I have personally built PWAs that work offline with JavaScript enabled, as well as with a network connection without JavaScript enabled.
It might be better to think of a PWA as a regular high performant "mobile first web application" that took the right vitamins. ;-) The vitamins in this case are usage of service workers and a "Web app manifest."
From my perspective, the "Offline First" + "Mobile First" approaches have produced the most progressively enhanced web applications that I've even seen.
Now I think about whether the downsides of relying on third party dependencies are outweighed by the upsides.
Supply chain attacks are real. Project maintenance suffers for many projects in the long term.
If you can write a left-pad function, just write left-pad.
If you are implementing a 200 page open spec for a system that needs to interoperate with 100s of other systems, consider looking for a community effort to rely on and contribute to.