The problem with mobile-first CSS

[@atrus3823]

For those of us old enough to remember, mobile-first was borne out of a lack of browser support for media queries. It was really an extension of progressive enhancement/graceful degredation. Now that media queries are well supported and we have lots of other options, there is really no reason to use mobile-first over any other strategy.

[@tnypxl]

tag gang, where y’all at?

[@vitalino1981]

I said that and got criticized a lot, they said mobile first is industry standard now, unless we do desktop only.😢

[@atrus3823]

@@tnypxl they moved to Florida with the table layout squad

[@atrus3823]

@@vitalino1981 there's a lot of dogma in web dev. You can make your case, but unless you're independent, you often just have to go with what your company wants. I think a lot of the problem is there is an assumption that not-mobile-first equals bad mobile experience. I personally find it less work and more intuitive to develop them all together.

[@MattThomson]

This comment best viewed at 800x600 in Netscape. Under construction

[@vitiok78]

I think we should break our design into logical components and decide for each component separately whether to use the mobile-first approach or desktop-first.

[@radvilardian740]

this is what always do, all depends on the condition. Having them aparts made my development easier to maintain

[@jovialcupid9687]

isn't this standard? I was doing it already in school (not in class ofc, in home) I always assumed that phone, tablets and deskop have their own versions. Few years ago it wasn't hard to find duplicate page address that started with m. (for mobile) Now line between phone and tablet is so small that (most) design will work on both devices, but still, really ppl aren't making special versions for deskop? This is not a standard?

[@ib6435]

I do that, and it is easier with SCSS, since the media query can be nested inside the selector. .container{ @include.mixins.minmq(425px){ ......style...... } }

[@issussov]

Consistency is critical in practical design. A mixed approach can cause confusion and a bad user experience. It also increases complexity, testing challenges, management hurdles, and overhead for documentation. A unified design approach is more streamlined and efficient for developers and end-users and aligned with SEO best practices.

[@sleepysud]

I use components with scss in my web applications and it is just perfect. some never even need to have different css for mobile / desktop and make the code complexity point moot.

[@zeddash]

If you do have issues going either way, don't forget that you can use `initial` and `unset` for properties to deal with them while not needing to state something explicitly

[@DanielRios549]

Sometime I prefer to not only use mobile or desktop first, but wrap everything inside its own media query, a menu is a huge example, a lot of the code you write for the mobile version was not reusable in the desktop one, so these styles needs to be inside a media query to avoid redeclaring styles to the default value. This is my rule: if a style is only needed in a specific device, it will always be inside this specific media query; but today you are having the opportunity to even avoid the use of media queries, this is really awesome

[@rubendacostaesilva8442]

I get what you're saying, because I mainly work with React. If the responsiveness is too complex, I just write two different components, and render them conditionally, according to the window size. I hate responsiveness so much, that if the project that I'm working on is not too complex, and I have the time, I just write two different websites, one for desktop, other for mobile, and call it a day.

[@DanielRios549]

@@rubendacostaesilva8442 I'm sorry man, but to be honest, this is terrible, different projects for mobile and desktop is something from 2010, and render components with JS based in the window size is even worst, don't do that.

[@theodorealenas3171]

​@@rubendacostaesilva8442interesting... Do you put the corresponding bits of code next to each other, or one app on one side and the other app on the other side? I'm more and more convinced that this approach makes sense.

[@CreativeB34ST]

To me as a web application developer for business applications, desktop has always been the more easy side of the responsiveness spectrum. Menus, forms, (search) tables, tabs, .. they're all easy to give a place on a larger screen. The complexity starts when we have to make it work on mobile. So from that perspective desktop first is so much more appealing. Additionally, most of our clients don't even want to pay extra for their web application to be accessible on mobile. Mobile first sounds great and all, until you meet reality 😅

[@rubendacostaesilva8442]

From my experience, most of the SaaS that I build at work, are meant to only run on local computers, inside the customer network (mainly you typical dashboard admin app, with a lot of tables and charts), and because no one is going to access it via phone, there's no need for a mobile version. I still implement some light responsiveness, because sometimes, because while the main users will probably be using small and cheap monitors, their bosses are using the latest 27" UltraHD 8K curved monitor...

[@Lord_zeel]

Yeah, I feel like the part mobile-first pushers ignore is that mobile designs actually have a ton of little gatchas and making the UX in a mobile layout any good is actually hard. Desktop layouts are just so much easier in terms of usability.

[@jovialcupid9687]

also most ppl was learning basics using 'big screen', not mobile one. This also shapes perspective

[@rotteneffekt4416]

True. On the flip side, projects get approved on desktop and then midway through they discover they want mobile too. I try to keep that in the back of my head when designing components and keep the presentation layer as free of behavioral logic as possible.

[@PanoptesDreams]

My solution to this is just to use remote software on my phone. Now I have a powerful desktop and portability :)

[@RussellSkaggs]

Mobile First is one of those mantra's that were much more important 10-15 years ago. Designing and Developing mobile first did largely just make everything stack, but it also forced decisions on priority leading to better structured HTML, and in turn making a more accessible document. I will still advocate heavily for pages to be designed mobile first to force hierarchy conversations earlier before larger screens are defined. But I believe you are right when it comes to putting it into code, it really is more about from broad to specific. This just tends to align with mobile first most times. Navigation and tables are two excellent examples of where Desktop first definitions may be the best route as its likely to also align more closely with the ideal markup.

[@VeitLehmann]

This is exactly the way I approach responsive styling. Try without media queries first, then style from common/shared to specific/complex. When you try to avoid media queries first, you'll also get a good sense of resilient design, i. e. make it work with unpredictable content and in unpredictable viewport sizes by default. We always design for the unknown. And: Code should be easy to extend/change, and the first simple, then complex approach, avoiding overwriting previously applied styles, also helps a lot with that.

[@Allformyequine]

Omgosh I'm so glad you are brave enough to make a video on this!! I think the SAME thing every time I make a new layout!! My brain says: 'do the mobile first; but reality says but you really need to think about desktop before" , so I compromise with myself and do desktop first with always keeping how it will affect the mobile at the same time. Like others say though I'm not working for an agency so thankfully I have that freedom. It is AWESOME to HEAR it said by Kevin out loud though! Kudos!!

[@chrisstucker1813]

Mobile-first design was a game-changer for me. Once you've designed for smaller screens then you've already done the hardest part...it's so much easier to scale up to larger screens than it is to scale down to smaller ones.

[@KevinPowell]

100% agree, most of the time at least :D - I still see that as more of a "path of least resistance" where you do all the styling, then add the layout/complexity at larger screens. It just so happens that for most things, we're doing that as we get bigger, but when we add the complexity at smaller screens, like with a navigation and potentially a table or a few other things, then the other way around can be easier :)

[@chrisstucker1813]

I agree. I used to dread slowly minimizing the window and doing my best to tidy up the page as each thing decides to fall apart as we get to smaller screens. With mobile-first you simply do not have to do that. Where you used to have 6 media queries you now have maybe 1 or 2 when tweaking the layout. But yeah, navigation is quite different and I always design for desktops first. @@KevinPowell

[@outpost31737]

I disagree I find scaling down from desktop to mobile just as easy. It's all subjective and personal preference though.

[@chrisstucker1813]

Interesting. It definitely is subjective, if it works for you then why not - we all have different ways of working.@@outpost31737

[@TheCocoaDaddy]

@@outpost31737 I agree with this as well. At first, I didn't think a "mobile first" approach was good because I don't think the focus should be on a particular kind of display. I always thought "mobile first" should be "mobile appropriate". Then, I took Kevin Powell's responsive design course and his description of "mobile first" really opened my mind and encouraged me to give it a try. I just haven't had a lot of time to dedicate to it. :) lol Since the sites I work on, I work on using a desktop system, I'm naturally inclined to not use a "mobile first" approach even though I do use the responsive mode in the developer tools to simulate a mobile device. Anyway, great point! :)

[@StephenBolger]

The fact that we can approach the same objective with a different approach from others, and still get everything to work as it should, is both good for everyone and complex for those learning how to code. It is definitely beneficial to understand the many considerations to make and the need to keep your mind open to your approach so you don't get locked into one approach when you can make your job easier with a smarter method.

[@PratyushTewari]

I agree with you. I think I automatically gravitate towards an additive-first approach. Sometimes it is a desktop first and sometimes it is mobile first.

[@Dale0001]

I build desktop first and simplify down for the same reason that the complex stuff that needs figuring out is on desktop and mobile is just usually stacking

[@TravisHi_YT]

Yep, normally a media query with flex direction col will fix 90% of mobile layouuts.

[@get-web]

With this approach, you severely degrade Google pagespeed performance on mobile devices. And often the user himself can notice various visual jumps like CLS

[@tossichugs]

Something I always appreciate is the questioning of the “status quo”. I like how you point out there can be use cases when we can just simply lean into using the browser and making our code not as overly complex. Sometimes mobile first is easier but also sometimes it’s not. Great video !

[@colinwiseman]

Exactly. The status quo these days seems to be super complicated layers upon layers of libraries and codes, everything bulky because computers can handle it...all to achieve what looks like super simple layouts...and not to mention the complicated JavaScript 😢 And the status quo states you must have gulp/vite/tailwind/node to do simple scss work. It just feels we've made our jobs harder some days 😅 I know I'm an old dog, and maybe I don't learn too many new tricks but it feels the world is finally (and happily 😅) going back to simplicity because it's really only the designers that want super fancy things, but actual users just want the content asap. (See the UK government website framework which is beautifully clean and useful...unlike the government which is far from either of those.)

[@berridgeab]

Resize Observer + Vue have been a game changer for me in business applications. I used to fill my web app with mobile and desktop HTML / CSS / JavaScript and then adjust with media queries. Now I can develop mobile / desktop components that only load depending on the current viewport size, and will automatically load and swap themselves out as the viewport changes. Components contain their own HTML, CSS and JS so I'm only fetching what's needed.

[@spicynoodle7419]

This is the way. Tryharding to reuse the same HTML for a table or navigation by writing 5k lines of CSS is terrible - if you need a little change everything starts randomly falling apart

[@wolverine9632]

I have always thought of CSS as "desktop-first, mobile-next", but maybe that's just because I personally prefer to use websites in desktop mode. I just think it makes more sense to treat your desktop layout as the "normal" one, and your mobile and/or tablet layouts as the "secondary" ones. I took a college class a few weeks ago on web development, and for all their examples, they forced mobile-first CSS design. The code took up twice as much space as it should have, and I had a very hard time remembering that my media query stuff was for the _desktop_ version. I spent dozens of minutes pulling my hair out over why something wasn't applying, only to realize it _was_ being applied, but only to the mobile layout. I like what you are saying here; "simple-first CSS" is the way to go!

[@BlazeShomida]

This video got the wheels turning. I’ve always leaned towards the ‘Mobile First’ approach, but sometimes it feels like a tug of war with styles, especially when mobile layouts are more complex. It led me to think about a ‘Simplicity First’ approach. Start with the least complex layout, no matter if it’s for mobile or desktop, and then venture into the more complex territories as we go. It’s like easing into the deep end, keeping the code tidy and our minds uncluttered. The ‘Simplicity First’ approach isn’t about ditching ‘Mobile First’, but more about embracing a flow from simplicity to complexity. It feels like a friendly handshake between mobile and desktop design, each learning from the other. Just a fresh perspective that’s been brewing post-video!

[@robopecha]

love this!

[@kaszapnagypeter]

I always start with the larger screen and then work my way down to the mobile view. This approach makes it easier for me to develop any website.

[@mistertoups]

I think mobile-first makes sense from the perspective of the state of css like 10 years ago. flexbox wasn't even standard yet, we didn't have grid at all, there were no minmax functions, etc. and it was the heart of the smartphone boom. but from both a design and engineering perspective the mentality never made sense to me and I'm so grateful we have tools now that make them mostly unnecessary. it's been my experience that the mentality is embraced by people who just don't want to deal with css at all. I begrudgingly respect that the majority of web usage is mobile, but I personally hate using websites on mobile because the experience is always so dumbed-down and flat. but what really bothers me is that mobile-first has led to bland homogenization of web design on desktop. 99% of desktop sites use the exact same format of vertically stacked segments under a hero image. it's not even mobile-first, it's mobile-only, and you end up getting a compromised user experience regardless of what device you're using. it does avoid complex code but like... at what cost??? thank you for making this video.

[@BenRangel]

For me, mobile first just was a mindset to stop getting everyone in the Dev team from only looking at the desktop mode and spending 80% of the time making compiled desktop designs despite a majority of users being om mobile. So much time was spent on details of desktop layouts that mobile uses never saw.

[@JohnCamacho]

I visually design for desktop first as that's generally the site to show the client. It's also the size with the most bells and whistles. As Kevin says the mobile version is generally just one column (sometimes 2 or 3 on tablet), so it's not a problem to adapt a more complex desktop layout down to mobile. The css though is mobile first, with the larger sizes overriding any of the default css.

[@philklc]

Remember two decades ago, before the smartphone era, websites were desktop only and there were separate versions for mobile, text only, PDAs and iPhones? Mobile first design means there's only one codebase for all the clients, and it is not just about layouts, but also about code structure. Mobile first plus some good use of semantic HTML meant if the HTML got loaded before the CSS file finished loading, the user still gets to use the webpage in a usable way, having a well-formatted menu at the top and the page contents after it. This is especially important for users with slow and unstable mobile connections. Wrapping desktop CSS in media queries was also a way to drop old IE support without cutting them access to content completely, they still can view the page in a mobile layout while we can use the latest CSS standards for desktops without worring about IE.

[@pinnaclewd]

I agree 100%. Most of my clients want to see a wireframe layout for desktop. I then explain how the design will cascade down to mobile. I won't be changing the way I do this for a while.

[@AtacamaHumanoid]

This made me realize I have never done "mobile first" even when I thought I was. I just always design with mobile in mind, so that I don't run into surprises, but I always put all the mobile styling in media queries.

[@canarymultimedia]

I think instead of randomly having to choose a break point for smaller screens it would make more sense to use a (new) media query which determines if a specific element has overflow. Would be great if somebody with influence could push this to the CSS specs...

[@sparklitd]

@7:56, I couldn’t agree more! I have been practicing Web Development for almost 2yrs, now, and I have always disregarded the “theory” of mobile-first design principles for this very reason.

[@Arzen84]

It always intersting to see how we the Dev's love playing with the "new toys" so we start using them at work then 6 month later we just fall back to something "basic" because it just feels easier or nicer to use :D It doesn't mean the "new toys" aren't great in the end it probably comes down to your personal preference. Mobile first approach is great and I usually start my design using it but we also have to adapt to different situations and shouldn't stick to only one pattern/approach. Really nice video as always Kevin! :)

[@dcts7526]

Love it! I always hated mobile first approach exactly because of what you covered in this video. Sometimes its just easier and less complex to start with the high complexity and reduce. Never understood why everyone always preached mobile first!!! Thank you for this video😀

[@benjaminkvist9207]

A concept that I've taken a liking to from the backend world is composition over inheritance. Especially for scenarios like this where the shared behaviour is next to nothing, and those that are shared could easily be subject to change for one context, so it's easier to just think of them as seperate contexts from the start.

[@thisiskdn]

I don't normally comment (long-time viewer here!), but I feel the need to point out how it seems like most people missed the main point of the video, and this might be due to the video title being slightly misleading. Judging by a lot of the comments, the discussion revolves mostly around mobile-first vs. desktop-first. The thing to understand is, going desktop-first with the same level of complexity and with just as many media queries is a problem as well. Kevin's point (if I understood it the way it's intended to be perceived) is actually not about mobile/desktop first but the "path to least resistance", as he says. The problem is simply how we may overuse/misuse media queries instead of properly leveraging the capabilities of the browser in the way we use CSS. I really think this video could have been titled differently to better reflect the points he discussed. I appreciate Kevin acknowledging at the start that he had also used this term "mobile first" in his videos because I learned about using a mobile-first approach from Kevin himself. I also learned from him many videos ago how it's possible to use a desktop-first approach just for that mobile navigation (exactly what he demonstrated in this video). It's just unfortunate when some misinterpret his message to be a "mobile-first vs. desktop-first" issue because his focus isn't really on one being better than the other; rather, it's more about the "path to least resistance" or even "simplicity-first", as some commenters said.

[@facu8888]

Makes me feel relieved, since I generally use a "default first" approach when styling. Nice video.

[@reaper84]

Navigations are these things where I personally prefer to render them twice, one for desktop and one for mobile. Its not only about these CSS issues but also about the DOM being structurally different to accommodate for a different design, making the CSS borderline impossible.

[@Blackmamba-ce3nb]

I do the same. It’s not worth the hassle

[@scnix]

Tbh, i never really accepted "mobile first" design. When someone tells me they want mobile first i just ask them why not just make it best optimized for all screens instead.

[@wchorski]

as a dev it's a wealth of knowledge to start development from both ends. The project and user base will dictate which platform is used the most, and that's where the focus will land

[@shogunkodogun]

I layout HTML after desktop design then start mobile first CSS. Makes it easy to scale.

[@oxonomy2372]

Learning so many gems since subbing to your channel. I’d love a video on general best practises and industry standards, especially for working in teams. As a newer developer who’s only done freelance, I’m sure I’ve got some bad habits and there’s probably things experienced devs take for granted that new developers don’t even know

[@thecyberhobbit]

Thank you for making this video... this has always been my approach and it's great to see some people admitting it has it's benefits. Mobile first forces you to write a property twice and from my experience makes the code so much larger.

[@buildervision7082]

I've always been comfortable doing desktop first and making everything work for mobile with media queries

[@Kevin-fl4rn]

Mobile-first is still the way to go IMO. It's always easier to add things on desktop especially since they are much more powerful compared to phones. They can deal with different breakpoints or changing code much faster

[@richprosper8562]

What I do is design the page for desktop-first but then code it for mobile-first. That's my way of getting the best of both approaches.

[@justmillenialthings]

With the icons, you could always add a ::before and use a custom font with those icons in it. Then you don't need to "hide" them at desktop sizes, and instead you add them at mobile sizes.

[@PerpetualWarr]

I find using multiple media queries per classes much cleaner approach, than one global media query and then slamming all other necessary classes in it.

[@KevinPowell]

I agree, to a certain extent. I really don't like the approach of one giant media query for everything, it makes things too disjointed. I do tend to have one for a component and whatever is nested inside of it though. But whatever works :)

[@feldinho]

One thing I really love about BEM-style organization is that I can have media queries per block. For me, it's a good compromise between one huge media query for everything and one media query per class/element. That works specially well with css modules; one query per module.

[@BenRangel]

Yeah, one global mq seems like something that only works in small projects

[@theodorealenas3171]

I went nuts with it once, and maybe I just don't know enough but matching up the numbers in the queries wasn't fun. It wasn't bad, but it wasn't fun either.

[@TheCocoaDaddy]

Brilliant video, as always! My biggest struggle with mobile is I HATE the hamburger menu. I understand it's purpose and by now, many more people are used to it, so it's not a mystery, but I don't like it AND I see it "creep" into non-mobile displays. This video has given me some great "food for thought" and I'll try this approach out on a project I really need to get started on. :) Thanks for posting!

[@CottidaeSEA]

I usually think minimal first. It tends to work out well. I think it is similar to this approach, it's not exactly the same in my case, but that is largely due to my lack of experience.

[@Guillen8606]

The first time I heard and learnt "Mobile First" was actually here with Kevin lool

[@PicSta]

There exist a lot of discussions out there which approach you should go with. Actually, there is no right or wrong, the truth is both have their pros and cons, and personally I go through my page layout section for section and decided when it is more complicated. Is it on mobile or on desktop sizes. Then I can decide in which CSS file I throw in my CSS.

[@theodorealenas3171]

I love the broader message, I think of it like the computer has feelings too. I love to exhaus all the cheap approaches I can think of, first. And this simple code can give a pretty good looking result! I went a little extreme and let my menu items look like vanilla links, blue and underlined, and then by tweaking the style of all the links it actually turned out pretty good! I'm keeping it. For now.

[@netsudro]

It took a lot of time for me to get used to the mobile first workflow. It's the same problem, I hated to unset a lot of properties for desktop, and hated building layouts for mobile. But using Tailwind and SASS made it a lot easier. Now I just set all the media queries inside the class. It still feels a little weird, but it's a lot easier to manage.

[@leontlangwini6256]

The title alone is enough to make you my hero for 2024, no one is going to top this👍✌

[@vintprox]

It's kinda funny to see you try to put up with mobile-last adventure there in the start. xD

[@posguy13]

Great work as always Kevin! But this debate is kind of silly, kind of like tabs vs spaces. Some people seem to think that choosing spaces means that you press the space bar x number of times. No, you still press the tab key, but instead of inserting a single tab character, it inserts x number of spaces for you. Mobile-first originally was coined as a term to instruct startups to focus on mobile customers first, seeing that most of their customers would be coming from mobile devices. Whether that meant developing a native app, or web-based content was never the point. And certainly nothing to do with developing your CSS for mobile or desktop clients first, then developing for the other.

[@virtual5754]

The best example I have seen was viral screenshot of bathhouse site. On mobile everything looks fine. On desktop main picture is cut slightly more than needed - it cuts out all towels and context of poses, so it looks like frame straight from adult film

[@owlmostdead9492]

Most of the browsing today is done on mobile devices, hate it or love it but that is a fact. So depending on your product, mobile first is 99% of the time the correct and smarter approach.

[@filmyk]

We sometimes have layouts that are so different from one another that overriding behavior in CSS is no longer an option because even the HTML changes between mobile and desktop. That's when we start to have two versions of the header, one for desktop and another for mobile; there might be duplicated HTML code. But in the end, we take all the common functionalities to a controller, and the differences can be better divided among components, making the complexity of each one of them lower.

[@mswondo]

I use approach, begin from device development first, then smaller smaller to implement the change of skeleton and then back larger and larger to improve and perfection it.

[@getellied]

It's an interesting thought, actually. I completely agree that it is much more of a case to case thing, and agree with people mentioning to keep checking how responsive (or unresponsive) the page is. I find myself repeating "mobile-first", but in reality what I do is understand how complex something is and how I can produce more with less code, thinking of maintainability as well! It's funny because I had some bad designs when I started where mobile-first would've been good. Then I learned about mobile-first, but that quickly transitioned into something way more flexible just because of how much experience with CSS I have now! It really is about understanding your tools and the system you have to work on which leads to good code-writing and maintanable structures!

[@uditkaushik8836]

I like this idea, write code which has less maintenance rather than choosing some standard because we have been told so.

[@anaf4072]

Hey thanks for telling it how it is. Everybody has been saying "mobile-first" for so long that it just became a part of our psyche. But the truth is there are very few devs who actually do mobile first. Sure they will nod in agreement but when comes down to it they'll do what makes most sense and it's ain't mobile first.

[@hassaanmaqsood]

When I started developing web apps, I didn't know about mobile-first design. It just hit me when the UI had go from landscape (desktop) to portrait (mobile) mode. The narrative took me up for mobile-first. Recently, as I am working on the web app for my company, mobile-first have become something that's just make things complex. With a bit of research, I found somethings to help the front-end faster and easier to develop: - Notion/Atom/VS Studio like design is universal in nature is the content is simple like markdown or editable. - There are some generic blocks layout and functions, that changes like a transpose or just dimensions like the search bar if primary function is to search. - Flex is much responsive compared to Grid - Design and develop the web app like it's a single-page web app, it would help to reduce less used components.

[@bernardwodoame9850]

I recently just started mobile first. It can get a little tricky when you want to move to a larger screen especially when the divs are not in good positions to do display flex. 😅

[@davidmaxwaterman]

I love this concept. I even "get" mobile first better now.

[@vitalino1981]

Kevin, You are one of my top favorite YTubers, and I subscribed to a ton of ppl. Wish U the best! Love your content ❤

[@Ceyesse]

In my previous company, Mobile-First became as much as a trending buzzword as Agile. The more people talk about it randomly through your work, the more you know they have no idea what they are … managing. Yes. Mobile-First was decided by management as a moto while it’s a technical consideration to be decided by the devs when the requirements are brought to them.

[@JohannesBrodwall]

For the simplified: replace `gap` with `inline-gap` for instant improvement

[@Ekitchi0]

As a simple user, I've noticed the mobile first approach affects design itself. I've noticed a lot of websites where the desktop version makes you scroll down endlessly waisting most of the horizontal space and making navigation tedious. Including sites like Apple's. Those sites are good looking but impractical.

[@Line49Design]

What i was looking for here is inclusion of the design phase. When a visual designer works in, say, Figma, do they design for medium screens ie desktop, or very small screens first? We design desktop first because it's natural for most websites. The layout is subsequently adapted for mobile. Building the site will naturally follow the same way. It makes sense for CSS media queries to use 0 as a starting point, so that aspect could be termed mobile first. But that doesn't make sense for the overall design and build mobile centric unless the project is something like an app that is meant primarily for phone.

[@fabsn182]

Mobile first never worked for me. But not because of resetting values for elements but because "Desktop"-sized layouts might need additional layout-helper tags, like a or something like that. You will only realize this after you've reached the point where the current html isn't sufficient, so you need to change it and maybe even change the CSS code again. Also I think it's better to start with the layout the designers created, and keep that version as long as possible, for example: change the menu to a "mobile" version only when the menu entries won't fit any longer. This also means I don't have fixed breakpoints.

[@ChibiBlasphem]

As I go through the comments it seems not many developers have an UI/UX team that provides design to them, like they seem to chose they want to implement things. In many of my experiences you get designs already done by the design team and all you have to do is replicate it with CSS, you don't really have a choice on "do I really need media queries?". What is true on the other side is that we should always do the less demanding (code wise) first and increase specificities after.

[@AndrewPolidori]

Here here! Using the browsers native capabilities is a great way to start! Venture out only when you truly need something very custom.

[@WakeMtz]

Most of the time the only component that is more complex on mobile view is the navigation. Mobile first will be the easiest and simpler layout for everything else.

[@daledesilva]

I love this. Well explained and demonstrated. ❤❤

[@th34lch3m1st]

I stopped using this brain-teaser/over-engineered responsive web design 5 years ago. And I've been a happy developer since than. 2 style sheets: 1 for landscape screens , 1 for portrait screens. VH and VW with percentages for all dimensions, SVG for icons/logos/graphic, 2 version of every image depending on screen orientation. It's a quarter of the effort compare to "responsive" web design. IMHO

[@Chladimir]

More straight-forward apporoach would be just to wrap mobile-version of the menu in mobile-only media query as well as desktop-only query. Then u have defaults on both ends and then it doesn't matter which goes first especially in components that differ completely as shown in the video🙂

[@crstnio]

The double selector has just blown my mind. LOL

[@ALex-ts1gu]

Thank you Kevin for your useful content.

[@WolfgangRechberger86]

Great video. But I would honestly like to generalize to "the problem with **add-any-design-paradigm here**. The issue is not that mobile-first, atomic-design, intrinsic-design or whatever have limitations but rather that people (especially in the web design / web development sector) too often see them as dogmas. For me it boils down to use those ideas as basic rules, but you always have to think for yourself (like you presented here very well) about what still makes sense and when to breake those rules. Thats true for individual projects as well as new paradigmes like Tailwind, which breaks every "common sense" of what we thought we knew about stuff like code and style separation and so on and still makes sense for a lot of projects / teams.

[@SteinGauslaaStrindhaug]

I always thought of the "mobile first" idea more like a restriction for the designers, more than any specific implementation. If the designer is forced to make a fairly linear layout for phones first, they are less likely to make a complex layout that requires a huge screen to be understandable. And forcing the designer to think this way was of course much more important in the early days of smart phones, because now all designers I work with think about how their wide screen design should wrap to a mobile design automatically. When it comes to the specific order in the css and whether to use min-width or max-width; it used to be important when we still had to support Internet Explorer; because whatever was inside the media queries would not be applied at all on those ancient relics. So my implementation philosophy weren't mobile or desktop first, but rather the medium sized screen compromise layout first (what we would think of as a tablet in landscape orientation size today) and specific very narrow screen and very large screen adjustments in media queries. Today nobody bothers with supporting IE; and all modern browsers support media queries, so it really doesn't matter if you put absolutely everything within media queries... in fact it might sometimes be easier to make a print stylesheet if everything for the normal layout is wrapped in media screen and something media queries. I tend to just have all the common styles (i.e. things that apply for print, mobile, tablet and big screens) outside of media queries, making it as responsive as possible without breakpioints, and just add specific narrow screen and super wide screen stuff in queries. And print styles tend to be just the common styles plus a bunch of display none of UI stuff inside a media print block. The common styles still tend to accidentally still largely work as an old compromise layout; but I no longer care at all if the menus are completely messed up and includes duplicated and redundant elements if you comment out the media queries. So I almost never display none things outside a media-query and then display block it inside one; that's just silly.

[@DAG_r8]

Ive been saying this since I first heatd the term. Thank you!

[@AleksanderFimreite]

I personally always prioritizing it this order... "Convenience of use (Function)", "Architechtural design (Code)", "Visual design (Render)". I can use an ugly webpage if it fulfill it's purpose. If the code is bad, it will take alot longer to develop. If the visual quality is low, it will probably only affect marketing. Comprimizing on the visual design is the lesser of the overall evils. And I think people should get better at making readable and user friendly functions before they consider how it's visually drawn. Unless you're making pages which contains only paragraphs, I suspect your functions needs to be fundimentally different for mobile. I would even suggest a totally different design, rather than to try re-purpose the desktop one. I practically never use mobile for anything but reading simple articles for this reason, because its just time consuming and inconvenient on most webpages.

[@JoeSnellPDX]

Interesting thought. I agree on strategizing development and considering the path of least resistance in your implementation. However, I still feel mobile first makes sense in terms of displaying "default" or non media query relative styles on page load and only using media queries as he viewport grows. I do this for 2 reasons. 1) there is a greater likelihood for users to have poor bandwidth on smaller screens and 2) maintain a pattern of consistency. That being said, depending on the design or component structure, I will often start at large screens and deconstruct as I reverse engineer for small screens. Either starting small or large, though, I try to plan ahead for the path of least resistance and using the power of the tools available to me (like your flex-wrap or grid examples / intrinsic design). I may just be old and used to this method of operations, but it works for me. (getting into react or other frameworks - could be an entirely different video - strategic thinking)

[@ronitgurjar5747]

Was looking for this since morning...and you posted it 😁🔥

[@LukeDorny]

Wow, you really jumped into the fire with this one.😮

[@mjdryden]

I've always thought mobile first was a misnomer...it should really be "multiple sizes from the start". If you focus on one and ignore the other you'll have more work to fix the one you ignored later. If mobile users matter you need to be switching between layouts regularly.

[@alankarmisra]

For me mobile first is just a way to figure out the extent and tone of content I want. I feel like with doom scrolling habits engrained into mobile users it becomes important for me to optimize a small screenful of information, low text density, high visual contrast, get the message across quickly and then spread that in a more easy going layout on the desktop. I find it easier to simplify and “slow down” a message than the other way round. But I understand that everyone is different and there is no silver bullet. Some prefer going from desktop to mobile and that’s fine too.

[@haliszekeriyaozkok4851]

Mobile first approach is just makes all layouts messy and complex, because we're coding this layout on computer, so we can more easily realize how it should work desktop first layouts and what changes should occur on mobile or tablet widths.

[@seitbekir]

Mobile first is not about css, but about a design. For sure, your solution must solve the problem, not create a new one. But focusing on style direction is pretty good way to resolve most of the requirementa.

[@Lk77ful]

it depends on the use cases, if your building something that will be used mostly on desktop, mobile-first makes no sense, example : management sites

[@GamingNightError]

To be honest I never understood why some people were preaching that we should stick to either mobile first or desktop first. The arguments of either side were never compelling to me. I always went for the ‘most-common first' approach which is starting from whichever side you are most comfortable with and then add exceptions with media queries if I know something is only for small screen or large screen. This way the most common code works on every screen size (which is most of it) and I pretty much almost never had to overwrite styles from one screen size to adopt them for the other screen size. I think the mobile first / desktop first makes sense for css frameworks since you have to pick a camp for consistency and readability but when working on the actual project it doesn’t make much sense to limit yourself.

[@aleaallee]

I tend to make stuff desktop-first then copy the CSS code into a min-width media query, the result ends up being the same. I prefer that approach because I spend 99% of my time in front of a PC, I barely use my phone.

[@EricFressange]

That's exactly the process I use and it's much more efficient

[@StuffIMade]

I have an issue with either Mobile first or desktop first... issues or problems pop up after the fact that you then spend way too much time trouble shooting. For the team I manage I have an approach I have called as 'Parallel development' and for the UX team 'Parallel design'. For each element we are considering desktop tablet and mobile in parallel, moving between each and deciding on what works, if i do this on desktop how will it transition to mobile and vice versa, what are the compromises. I think it is just about being more fluid in where you need to start based on the complexity and moving back and forth to achieve the end result with efficient code. `Thanks for having raised this issue on your channel... too many non technical managers site mobile first as a requirement without know the implications of this. CSS, Grids, Flexbox have all changed how we develop, so this mobile first thinking is already old school.

[@modernkennnern]

Generally speaking I think you should _add_ content conditionally. If that means "min width" or "max width" depends on the context, but in 9/10 times there's less content on mobile.

[@BW022]

Well, the first questions should always be: Who is using this and how? I've been part of meetings where stakeholders and developers have spent days arguing about mobile on a web site where I finally asked the question... how can anyone use a web site with forms containing dozens of fields including drag and drop on a mobile device? The average form needs 500 words of data they need a keyboard and the drag and drop doesn't work when the mobile screen forces you to scroll to the 'toolbar' go grab and item and then scroll while trying to drop it on the appropriate 20 pixel box with your finger. I remember with one site, they spend I don't know how much time they spent on "mobilizing" it only for me to pull up the usage logs only to find that no one was using it on a phone or tablet. If you do a lot of data entry, complex UI, display large amounts of information, etc. often mobile is a distant secondary approach. Likewise, there are web sites where so many people will be using mobile (and often phones).

[@phantomas1225]

Creating a website from scratch with "mobile first" in mind is good, but I'm not sure about switching from desktop first to mobile first. I did it on a huge website, it took a lot of time (not even ChatGpt was very useful in making the transition) and in the end the lighthouse scores were just a little bit better. In my case I would say that I lost time doing it. One thing that I found particularly annoying was using the display: none. It's easy to use it in media queries when you start with desktop first for any type of elements, but things become awkward if you start with display: none and then you give it a different value in the media queries, because that element could be a table-cell, an inline-block or something else, so you need different definitions for different types.

[@dweblinveltz5035]

"Path of least resistance" is a good paradigm for design. Often, mobile-first will satisfy this criteria, but it's worth keeping in mind when implementing a UI design.

[@get-web]

For elements that are very different, you need to write separate components for min-width and max-width. At the same time, it is better not to mix them and not try to create common styles.

[@raswonders]

I personally start with mobile first as the platform is more constrained and weird. I benefit from early mobile prototype greatly.

[@daledesilva]

In the navigation example, if they have to work differently, I have a personal approach of building 2 sets of navigation and turning them on and off at different screen sizes. I find this removes the dependencies on each other, and allows for more intuitive code organisation - both of which make updating each easier. It has a downside of have two things to update if the options change, but I find that’s often much simpler than handling css inheritance dependencies that are easier to miss. Have you ever taken that approach and does it have other issues I’m not aware of?

[@IvanKleshnin]

As soon as DESKTOP and MOBILE menus start to diverge (and that happens, especially with larger menus) - having them separate in HTML/JS code immediately becomes the best approach due to its flexibility. And if you separate data and markup - even the issue with duplicates disappears.

[@TimbavatiLion]

Meh, i never really did mobile-first. I design two layouts at once: mobile-portrait and large screen desktop. I then develop it to work that way. Media queries only come into play when i start resizing the window to all and any sizes and notice the layout breaking at any point. Which usually ends up with 2-3 media queries. Which also is my answer to "what breakpoints should i use?" - when the layout breaks.

[@MKRhere]

Whenever I mentor a new webdev, I first teach them what mobile-first design is, and then I tell them, "we don't do that here". Then I educate them on the alternative, which is to avoid media queries until they become an absolute necessity. A lot is possible with only flex/grid. We design with that in mind, and add media queries for the more complex parts later.

[@lesalmin]

I think the most important thing with mobile design is usability; just to remember we may use that page with our big fat fingers on a small hi-resolution screen without a chance to hover over elements.

[@isaiahdavis3350]

I think the optimal word here is "Design" in Mobile-first. I think as a developer you have to critically assess the design to understand the path of least resistance when coding.