All Programming Is Web Programming (2009)
blog.codinghorror.comThe advantage of web applications is that you do not have to install and update them, that they are inherently sandboxed, and that they are not operating system depended. And even those are not universally good things - server down or no internet connection, no application, feature removed in new version, good luck trying to run an old version, and operating system dependencies give way to browser dependencies. And you have turned even the simplest application into a distribute one unless you put in the effort to make it work offline from the browser cache.
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.
I was gonna say that this comment seemed like something from a decade ago... before I realized the article itself is from 2009 (12 years!!)
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.
> server down or no internet connection, no application
Service Workers https://developers.google.com/web/fundamentals/primers/servi...
> At some point you browser will just turn into another operating system running on top of your operating system.
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.
> 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).
>At some point you browser will just turn into another operating system running on top of your operating system.
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.
> server down or no internet connection
A number of web sites work offline, ie google docs.
It's interesting. 12 years have passed, and I still prefer a native (not Electron) desktop app to its web equivalent for practically any task, from writing code to working with spreadsheets to PCB design. Even for such a basic task like word processing I prefer to use a local program rather than a web app.
Every Electron App teaches us a story, often stuff like "time to market" and "we cannot provide stable APIs" and "we don't pay your RAM" and "it is okay that it's slow and laggy".
Me too. But this rant still resonates and speaks to a snobbery that's still occasionally alive.
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.
Yeah. It almost feels like there's a ceiling on quality imposed by the platform. 60fps is still seen as an aspirational goal for webapps, and most apps we use everyday are just...okay.
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. :)
> 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).
That's true - though most apps I use on my phone respond like like webviews.
Word processing is no simple task.
I agree, that's why I said "basic", not "simple". Basic in the sense that we had them for over half a century and everybody is using them. The amount of thought and engineering needed to build an efficient word processor still amazes me.
yeah - unfortunately, it gets harder to find native apps every year...
I never get why CRUD work is looked down upon by many on this site amongst others. Most applications are a variation on CRUD. A well done CRUD app should be pretty simple, but simplicity is not something that our industry encourages, the interview process often selects for the ability to produce complexity. As a result most CRUD apps (certainly the ones I have inherited) are an over engineered mess.
It's because people get bored. With CRUD apps, the challenge is (should be) in the domain, wrangling that into a comprehensible shape. The various layers and code should be boring - input, validation, API, business logic, persistence. It's the kinda thing that can already be built using visual programming tools, drag and drop interfaces or a single config file churning out a fully functional CRUD API with all bells and whistles.
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 trying to work out if you are being ironic in your reply or not.
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.
I'd say @Cthulhu_ is giving the real reason we'd tell our friends in the pub, rather than the bullshit justifications we give our managers.
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.
> More code is a liability not an asset.
Unfortunately not all managers agree on that point,
Generally, that less code means relying on someone else's code which depending on the circumstance could be a bigger liability.
Using well tested libraries is likely more reliable than something I have written myself. Though in my personal experience Python (or Perl) libraries seem to be far higher quality than JavaScript libraries.
I used to feel this way, strongly.
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.
Yes, I am pretty much in agreement with you there. It's a balance, and as you say smaller things may well be better without a library, but larger things maybe not. And there are going to be exceptions to this rule of thumb.
I often used to say (somewhat in jest) that it takes a million microservices to build one service.
> 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.
Well you have automatically gone for a SPA app architecture, without giving any reason why. Looks like your problem is practising resume driven development. CRUD apps do not require SPA architecture.
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.
Keep state on the server. Start with zero javascript.
And how would my app work without internet, I that case?
Why exactly are you worrying about this case? Start with a simple server-side rendered forms-based web app.
Because it's a very basic requirement for a mobile app.
Then maybe it is a PWA that you are looking for. But this fine site we are using now works 100% without javascript. And it is fast.
The "P" in Progressive Web App: https://infrequently.org/2015/06/progressive-apps-escaping-t...
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.
Then you should build a native app. I never expect any web apps to work offline. If they do, that's nice, not expected.
> Sorry Jeff, but your post from today is simply stupid.
> 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.
Maybe yes, but really no.
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.
Well, web apps routinely interface with lower level systems like databases, and file systems. I don’t see why interacting with an embedded system is any different.
OK, but what Oracle does in writing their database is not "web programming", by any reasonable definition. I don't care how many web programs use it as a lower level. Ditto Windows creating a file system. That's not web programming in the same way that it wasn't GUI programming 15 years ago.
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.
Huh, if the C guys were laughed at by the assemblies, the pythonistas by the C guys, I can't wait until the day that something emerges that Starbucks-chugging hipster 'React code-artisans' will be able to laugh at.
"Oh, you think you could adequately program a neural interface using Scratch? How quaint"
Framework fanboys have been comparing writing JavaScript without their stupid framework to writing assembly since jQuery was a thing.
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.
Where do Cobol, Java, C#, Basic, Object Pascal, C++[0-9][0-9], Tcl programmers fit?
Low/no code fits.
Wow this is a super hostile sentiment, either web or gtfo.
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.
I like Jeff Atwood’s take on a lot of things, but this article has always been so thought-leader-y to me. Feels like it was written to make a splash rather than convey truth.
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.
I've the same impression. Looking around I see a lot of native host based programming happen, not just Neovim or LSP but also the broad range of apps for smartphones. Usually total statements aren't true.
What would people appreciate? A native client for Slack.
A programmer that doesn't make websites is like a glass artist that hasn't made bongs
You have mixed present work for the programmer with past work for the glass artist (blower?).
There was a time back not so long ago when there was a craze to rewrite every desktop app as a webapp because the web was going to eat everything. It was the hype cycle of web 2.0. Those days are gone imho. Instead it was mobile that ate everything.
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.
I remember agreeing with most of this post when I first read it but I don't think we'll see a continuing dumbing down of code. Blockchain, whatever your view on it, is forcing a lot of developers to write low level code with an understanding of garbage collection, abstraction, etc. This is also being felt in data science in which AI models are getting more and more complicated and the only way to scale them is to write lower level code.
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 has happened. These days desktop apps are Electron. Even in the mobile apps the native UI parts are mostly navigation between various WebViews.
I read the interview of Philip Greenspun in Founders at Work recently and in it he says that he realized applications will be written for the web in the future because you don't have to deal with different operating systems. This was early 90s. It's really amazing that this had actually happened by 2009, and the author of the quoted blog did not yet get it.
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.
What's worth nothing, nowadays most of the concepts "that are too hard for web developers" In the quote are already part of frontend programming.
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
> 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.
Noob question. Aren't primitives immutable? Does it need distinguishing between Value & ref types?
Compare:
The first one behaves like passing by value, the second like passing by reference.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.
Objects are always treated as a reference, primitives as a value. To say they're immutable requires a bit more of a context - immutable in what sense? You can reassign a different value to a variable that stores a primitive, so it's not like variables that store them are immutable.
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
Not sure about Atwood's Law.
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.
What's wrong with JS syntax? Seems pretty modern and adequate for what it needs to do
Maybe what it needed to do, but not what people do with it now. There are entirely “enterprise” systems coded in that thing. It’s an human problem, original JS syntax was fine imho.
Personally, I think that the original JS syntax is absolutely horrendous and is in no small part responsible for the bad reputation JS is still shaking off. Modern JS in comparison is an absolute dream.
I don't think js was ever all that bad, little ambitious however. But modern JS now checks off nearly all my boxes.
I find in hard to know where things begin and where I am executing in a JS codebase/library.
This may have more to do with the async nature thereof than the syntax specifics.
I still find it unfortunate that the guy who invented JS originally wanted to make a lisp but was told to make it more like the C family. Would've been interesting to have lisp run the web. A lot of things might be different today.
(2009)
I don't mind older content, but I think on this topic it is pretty relevant because 2009 had different requirements for web devs compared to today.
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.
the year isn't a knock on it for being "old", it's important context