See the entire conversation

The problem is that nobody really does "mobile-first". ~everybody designs/builds on desktop, and few know about or use chrome://inspect as they core of their workflow:…
Mobile-first responsive design works. The alternative is far worse—separate code bases; separate m. sites? Never again!
October 4th, 2019, 3:34pm
Mobile-first responsive design works. The alternative is far worse—separate code bases; separate m. sites? Never again!
74 replies and sub-replies as of Oct 11 2019

When you build with desktop-era frameworks, to desktop resource limits, only occasionally (if ever) marking your experience to the market reality of the median or P90 device, you lay down a structurally broken experience, one brick at a time.
Browser DevTools (including Chrome's) don't do nearly enough to highlight how bad the situation really is, and how deeply unrepresentative the developer devices are, even when "emulating" slower CPUs & Networks.
Ground truth is a $100-200 Android, attached over USB via chrome://inspect, or automated via @patmeenan's genius Anything else is just lying to yourself.
Free idea: there should be a service like BrowserStack that builds a DevTools extension that lets you subscribe to see/experience your dev environment on real hardware by default. Opening DevTools should never reflect your local device capabilities by default.
added page to bookmarks 👍🏼 I thought you talk was incredible! Even though it was a bit depressing for someone who is just starting out, thanks for that 😋
Which is a better test case - a recent model cheap one, or an older second hand one at that kind of price point?
Speaking of low-powered devices: Which one would you recommend to test on?
Moto G4 gets mentioned quite often
The fact that we broke chrome://inspect in Chrome 77 and I didn't immediately get inundated with bug reports is telling.
Why doesn't Google make a nice/professional looking web page test and have it integrated in devtools?
Be very cool if DevTools showed warnings in the console output on poor performing pages.
Lighthouse is there, but no one seems to care...? I’m guessing this is common: “It cannot be that bad, something must be wrong with Lighthouse, so I keep my code”
It's a small thing, but it always bothered me that the Network panel always hides the uncompressed size (unless you go out of your way to reveal it). Half of our tools report compressed sizes, and the other half uncompressed ones. Makes it hard to talk about perf budgets.
Do you anyone who might be able to improve that?
Like Jeremy said, genuine mobile-first can work because if you’re building for low-powered, small devices, you’re not going to accept heavy frameworks clogging things up. We don’t need frameworks. They’re mostly Dev experience tools. Dev experience needs to be de-prioritised.
In fact, I’ll set myself a challenge. This mini-course will be built low-powered first. It was already mobile first (notice how the static design is mobile first), so I might as well go the whole hog.…
Some WIP design stuff. In preparation for @cssfromscratch, I’m going to do a mini course where I teach you how to build a landing page from a static design. I’ll be diving into the C-BEUT methodology that I outlined in “Keeping it simple with CSS”, too.
I like to think of it as the hardware equivalent of the broken 'graceful degredation' approach of designing for high end devices first, as opposed to the progressive enhancement approach where your start at the baseline.
Doing an analysis into why this is would be fascinating.
It’s not “nobody” but I agree that it’s Sturgeon’s Law in action; 90% of responsive sites are crap because 90% of websites are crap because 90% of everything is crap.
October 5th, 2019, 11:12am
It’s not “nobody” but I agree that it’s Sturgeon’s Law in action; 90% of responsive sites are crap because 90% of websites are crap because 90% of everything is crap.
Explicitly added the "~" to account for the rounding error fraction of folks who are doing it right. Most build in & for desktop context and fail to do mobile-first. They aren't doing RWD as you and I understand it, but they call it that. The words were stripped of intent.
I think Sturgeon was being overly generous 😁
Was thinking about this after your talk. One thing that would be AMAZINGLY helpful is if the Chrome DevTools shipped with a Median Device Mode, which opened the page in Chrome on a median Android device w a median data connection in a dc somewhere (tunneling to localhost).
Even better if *mobile* Chrome could do this, so I could hold that experience in the palm of my hand.
This would be great! Years ago, I asked DevTools team for this, and if not possible, enabling existing (low-fidelity) CPU and network throttling when a device is selected to emulate. Was told "no" so often I stopped asking. /cc @paul_irish @aerotwist @expatdanno @dalmaer
😕 It doesn't HAVE to be built in to DevTools, the big cost is the infra and support. Peanuts, really, and the alternative is… letting Search die. It seems categorically insane to me that G would do that, but perhaps the right folks aren't thinking about it in those terms.
The good news is that Chromium now powers the crawl (which means we can drop "SSR" and framework bloat), and speed as a ranking factor (driven by real-world perf data) has changed some behaviour. But not enough. Not nearly enough:
Using page speed in mobile search ranking
Official news on crawling and indexing sites for the Google index
This is reminiscent of the “cross-browser” experience from 10-15 years ago: sites that “worked” in IE 6, 7, and 8, but barely.
It really doesn’t help that we have almost zero web dev tools on mobile. One thing that pushes this desktop centric view of development is the fact that dev tools are tethered back to the desktop instead of being on the device.
We need to start thinking about "browser emulators" much like native mobile developers have their runtime emulators integrating with their developer tools. Tools like or… are good starting points.
Sizzy - The Responsive Design Browser
Made for designers and developers. Make your life easier and instantly preview your website across multiple devices.
I hate to say it, but these approaches are themselves endemic of a desktop centric view of the world. People do complex workflows on these devices and the devices are scaling up to tasks like programming. On device development and debugging should be first class.
Not buying that narrative. We are yet to see complex workflows and app building on non-desktop-class devices. iPads/Surface are now desktop class, and is ripe for a new gen of DevTools to target mobile while the laptop fades away.
I know a few people who were doing development on iPad before it was “desktop class.” In terms of the browser that literally just happened and I’ve been doing development for a year on iPad. Yes, the tools suck, but that’s a failure of browser vendors not of developers.
Basically, the reason you see less programming on these devices than other professional workflows is because the vendors who create dev tools and browser haven’t taken it seriously, not because there isn’t demand or the devices are incapable.
Like, it’s sort of obvious but I still have to say it, these devices are significantly more powerful than any of the hardware we all used to learn programming. Web Development in particular is not a very compute heavy task.
I think you are mixing the two group of devices "desktop-class" and "mobile". I agree that desktop-class devices like iPad, iPad Pro and Surface indeed lacks development tools, as they have transitioned from consumption to productivity where people create. It's a ripe market.
Mobile on the other hand have super powerful hardware, but we are yet to find a meaningful way to provide the existing paradigm of developer tools in a meaningful way due to the interactions/touch/etc. LowNoCode tools might change this completely.
have you seen any of the mobile “learn to code” tools? They are quite impressive and have dealt with most of interface issues. Check out mimo.
Yeah, they are great! But educational isn't the same as mainstream programming. I really hope we'll see some of the NoLowCode platforms enable building from mobile. My hypothesis for now is that it requires code to go away, and get replaced with higher-level abstractions.
I think you believe that a much higher degree of tooling is required to do programming than is actually necessary. Regardless, there really is no excuse for browser debugging tools to be absent on mobile browsers, even if you believe people aren’t *writing* code on them.
It's a good excuse, and simple business: Don't built tools people won't use. The web platform is application runtime, and should have clear separation tools and runtime. Tools should ship on the platforms where people author: Desktop + Tablets targeting mobile-first apps.
You realize this is the only use case where anyone is even entertaining the idea that people aren’t doing something on mobile because they intrinsically don’t want to rather than it just hasn’t been enabled by the vendors?
Not sure we are talking about the same thing. There's a significant difference between "targeting mobile" and "authoring on mobile". I'm talking about targeting mobile from desktop-class-devices, and I agree with @slightlylate that we should build tools that this by default.
I'm yet to see developers wanting to build apps and websites from scratch on mobile devices, and I don't think this is caused by lack of traditional devtools, but by the interaction model with no keyboard, etc. GitHub, Glitch, CodeSandbox, and others should be good proxies.
You’ve yet to see it because it’s literally impossible because browser don’t ship any tools to enable it. You can pair a bluetooth keyboard to a mobile device BTW.
A very large number of people in the world have access to a smart phone and not to a laptop. When we treat these devices are purely consumptive rather than creative we subjugate those users to be only consumers rather than producers in new economies.
I’ve seen someone, on a plane with no internet, use a hacked kindle and a bluetooth keyboard writing code in vim. There’s nothing about this hardware that is so limited it can’t be used for programming.
Indeed, there's no hardware limitations but we have several UX/interaction limitations, which have started getting expanded into multi tasking on larger screen devices in iPadOS. Hence my earlier point: DevTools and editors for iPad is a ripe market and is next.
what UX/interaction limitations? programming requires a terminal or a text editor w/ a compiler. you’re saying you can’t do this on mobile? there are dozens of examples already.
Again, you are mixing concepts and scenarios here. Are we talking about web development and browser DevTools, aka front-end work with visual inspection or back-end programming?
Just wanted to say this is an extremely interesting argument, and you've won a convert. (CC's removed.)
This makes a lot of sense to me. The model I have in my head for "developer" is "well-off American sitting in an office" because that's what I see. But I learned to code on garbage hardware in an unfinished basement! Who are those kids today? What do they use? I should find out.
During Firefox OS we had some prototypes around basic web authoring for mobile-first countries. Primary use case was creating online shops (an important one to break out of walled gardens).
on android termux is really good, along with hacker keyboard for when you don't have a bluetooth keyboard handy. it's got bash, git, vim, gcc, node (but there are some bugs with node still). a lot of debian packages have been ported. and you don't need to root the phone
can't remember if i got rust working on it. but I think the main limitations for phone are the lack of a debugger in the browser (as you say) and poor amount of storage on most phones, even mid to high tier ones. a lot of dev stacks require a lot of disk space
still, browser dev on-device is much easier than getting the android sdk set up inside termux to compile native apps (and it takes a huge amount of space)
You are disregarding the overall UX and authoring/debugging workflow. I'm yet to see even conceptual UX work that looks somewhat like to be successful/productive. Enabling access to CDP alike is the simplest of it all.
You’re talking about a highly specific toolchain you prefer for development. I use basically none of this and am a fairly productive developer ;)
I'm yet to see vast segment of developers wanting to code on their mobile devices, and this particular conversation is about browser DevTools :)
I have yet to meet a Web Developer who is happy that they have no DevTools on mobile😅
Forget programming, sometimes I just want to inspect an element so I can remove some garbage in it. Or, goddammit, just a console that shows me the errors the page is generating. This is not rocket science, this does not require some new UX, this is BASIC SHIT.
Even if you *have* a desktop, setting up the remote debugging a pain in the ass if all you want is to see the errors the page is generating.
Good luck fitting all of those tools into a 5 inch screen with no UX for multi windowing ;) Might be basic shit, but we haven't figured it out yet.
there are mobile browsers with a basic console today, this is not actually hard. there’s a big gap between the nothing major browsers ship with today and where they should be.
also not hard.
But this is.... Our current generation of tools don't allow us to *target* mobile *from* mobile, and I'm not convinced that retrofitting our existing tools without rethinking the UX and interactions will do it.
the old phone i got second hand for free has more cores than my laptop
Yep, we're still doing this the same as we did in early 2000's. Still remember how cool (but not quite right) the WinCE emulators were
Wait. What? I’ve been building mobile first since responsive design became a thing. People… don’t? How the cock do any of their sites ever work?
This is a problem. I do my development primarily with the mobile view enabled & dev tools docked to the right. It forces me to make a mobile usable experience. Desktop then just happens in most cases.
I'm in a bootcamp now and we are told to start at mobile and work our way to desktop. But mobile is the default target for everything.