Laptops are all together awful. I can't imagine working on one for more than a few hours.
My self built desktop blows any laptop out of the water in speed, comfort, reliability, upgrade / repair potential and ergonomics (obviously ignoring portability).
I personally hate traveling with my desktop setup...
Everyone can probably agree that a desktop is better if you have the space, don't need to move it and doesn't mind a bit higer power consumption. A laptop has some clear usecases to.
Desktop for work, laptop for when I travel and might have to work.
I cannot imagine sitting in one place when working. I move, with my laptop, from desk to the couch to the outside table to the gym to the coffee shop to the bar. If I had a desktop, it would gather dust in 2 seconds flat.
But then you did say ignoring portability, so it depends what you value most, as most things do.
Portability is the first thing I look for in a work machine, personally.
I have a nice desktop setup, 5k2k, keeb, trackball, stream deck, my laptop runs it without making any noise, slowing down, or otherwise misbehaving.
I can easily drive to the manufacturer's authorized retail outlet in the event that it has problems, which has indeed happened twice over the nine laptops I've owned from this manufacturer in the last 15 years.
YMMV. Brand not mentioned out of respect for the aesthetics of this thread.
Where are you going with your computer to do real work? I've never used a laptop to get real work done where I need to sit for 4+ hours that wasn't a nice desk with ergonomic chair and large monitors.
The only thing I ever did with my laptops when it wasn't plugged into a docking station at a desk was surf the web, and I can do that from my phone.
I have a standing desk, gamer-style ergo chair, a Lay-Z-boy, a bed, a table and chair outside, and a cafe nearby I'm fond of. The laptop can go to all of those places.
I can't work in bed for hours. But I can for a half hour after lunch, take a nap, then set back up at the desk as I am now.
I lived without a monitor for several years, you get the hang of it. I did have to bump up from 13" to 16" so I can use it without reading glasses for a few more years.
I'm definitely more efficient with more real estate, but not in a way that holds me back most of the time.
I've also trained myself to type on a laptop in a way that's hard to describe but: left hand V to Q, right hand N to P/[, so at a natural angle for my wrists. I've been using a split keyboard for long enough that twisting my wrists to accommodate a narrow keyboard isn't something I was willing to keep doing. This lets me get paragraphs/pages written without pain, whether I'm at the desk or not.
I massively prefer a good workstation with large monitors and a nice keyboard, but I've done plenty of real work on a laptop.
Airplanes, coffee shops, recliners, internetless cabins... a laptop's been all I needed for doing everything from web development to audio synthesis algorithm development.
In practice they'll be hooked up to a display wherever someone works (office or at home), although I guess a select / elite few get to set it up in a coffee shop for a while.
In terms of speed, at least when we look at mostly single-threaded work load (like most dev work is), a M2 Macbook Air is faster than every Desktop PC. Correct me if I'm wrong.
Eh. The 12900k still has the edge in most single threaded benchmarks, and the latest Threadripper Pro will easily crush it on multithreaded loads (all while drawing close to an order of magnitude more power). Also your MacBook Air will thermal throttle if under load for too long, while a desktop computer offers a lot more options for cooling. Further more a desktop computer gives you the option to use faster storage and more and faster RAM which might be very relevant in some scenarios. Plus there is the whole GPU/CUDA side of things which may or may not be relevant to you.
All that being said, I'm typing this on an M1 MBP and the perceived day to day performance is better than any desktop computer I've owned, even if it will no doubt lose out a 'real' workstation when it comes to running 24 hour CFD simulations.
I suspect that if I crank my I/O subsystem to do flushes no more often than once in 40 seconds and lie to fsync/fdatasync, my Threadripper setup is also going to run circles around my M2 Air. (Heck, I suspect my XPS13 will be almost on par.)
But then again, the M2 Air has this bulky UPS called „laptop battery”, so they can afford such little lies as long as the OS itself won’t shit itself and die randomly. Granted, it happens rarely, but nevertheless.
For instance, when you send a message from the backend container to the database container during ordinary CRUD, the backend container will largely be waiting for the database to start processing. Something similar for most frontend requests - usually in dev work, you press a button, it sends an API request and awaits the response; the API request sends a message to the database and blocks on the response. The database sits around idly waiting till it receives a message, and sends something back. Then the backend postprocesses the reply and produces the response, and then the frontend postprocesses the response. There is some degree of joint action during the actual communication phases but it wouldn't put a huge load on the multithreading capacity of your CPU.
Something similar can be said for Gitlab/Slack/Email - in the background, they could easily be using the spare CPU time rather than competing for time, and you wouldn't actually notice it. But they also should spend most of their time waiting around doing nothing.
So I think the claim is specifically true for some stacks with poor test coverage.
But if you have compiled code, it should probably be compilable in parallel (and if it isn't, you should be complaining to the compiler writer and/or refactoring your code). Likewise, unit tests should in practice be runnable in parallel - if they are not, they're probably closer to integration tests. Even integration tests should be writable so that they can run in parallel, because you hope to have more than one user acting in parallel. And you generally shouldn't be testing your feature development manually. Even if you prefer to visualise your process, you can code it up in something like cypress so that you can run them later or check up why you missed this special case when the bug reports come in.
So I disagree with the original assertion, but I don't think you've provided an effective counterargument.
