Really crappy web browsers download

I was just having a debate with a co-worker about the advantages of fluid vs. In general, I disagree that fluid grids give more benefit. I think it is entirely appropriate for many projects, but I view it as an option, or even preference vs. So as a result I think the advantages and disadvantages of both zero out in the end. As we grow into the future the responsiveness of the devices and apparently architecture!

This article really opened my eyes to the possibilities of responsiveness in design. Like you said, this kind of forward thinking turns the desired attributes of the print medium into a handicap, and lets us explore the possibilities of the web. Excited to implement the concepts taught here! I hope the notion catches on and, with continued refinement, alleviates the problem of accommodating device capabilities.

One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. However it did come across as idealistic and mostly not practical.

And then I read your article. Larger displays see the entire layout as normal. No new mobile specific content or pages, no Javascript required and no content to repeat and duplicate. I look forward to integrating the technique further as I get better at this. The concept of a responsive design realized with media queries really got me, I instantly had to play around with it on my recent project, CouchCamp. I think this might turn out as a great way to progressively enhance even small budget projects for mobile devices.

Looking forward to experiment more with it on future projects. Thanks for sharing that, Scott! And Jim , you raise a very valid point.

Designing for a reference resolution, and then considering which elements are appropriate for another medium is another part of it—and to use your oversized image example, that may mean suppressing them altogether.

Kristina , I love the CouchCamp site. Beautiful and quick! A real eye-opener and what we can expect to be doing more often. A couple of notes regarding performance: img height and width are essential for fast rendering as the browser can reserve the space before downloading the images so you will have a possibly negligible performance hit if you go with scalable images.

It must serve usability. Secondly, YSlow and PageSpeed are fallible. In fact, the number of requests is becoming less important as browsers and bandwidth develop. I keep reading all these articles about doing things in new ways and i get excited and then I come to the realization that I cant use them because not everything supports them. By the time all the browsers do I probably will have forgotten about this article.

However, I was pondering about the fact today — optimization or, responsiveness , towards displaying web content consistently in various devices. After reading this article and stopping to think for a bit. On the other hand, should everything in a website resize to fit the screen? Or, should we only resize the blocks and images like the example created?

A very interesting way to look at it. Charlie Clark and bpaul , I dig that your two comments showed up together. Charlie Clark , you raise some interesting questions. As I mentioned, there are patches available to help close that gap, and support is only going to improve. Thanks for this excellent article.

I have to give a session on this next month and this has crystallised what I ought to aim for. Congratulations Ethan! But when I try to narrow the window to pixels in my MacPro with Firefox 3. Instead, the third photo of each line is clipped out of the window. Thanks very much for all! Great article and well argued, however, there is a substantial degradation in performance when using conditional statements in CSS. It is widely recommended to avoid them at all costs.

I think every project is unique and for some, this solution is warranted. For the vast majority of projects however, performance is of major concern — especially on mobile devices. A targeted CSS file would result in lower file size, increased client performance, and more legible and maintainable code. WHelman , thanks for the note.

Are you aware of performance-related issues with the former, however? If so, could you share a few references with us? Great article, the fact that I just noticed a hit to my site from Opera for the Wii reinforces this article. Where do we get the figure from?

Thanks for the question, Nick. However, both iPhones and Android phones simply lie. They lie about their sceensize, pretending to be far wider than they are. They insist on rendering the large screen version of the page, which is completely unusable on a small screen.

Two quick things:. By default, Mobile WebKit will render a web page at px. I believe Mobile WebKit simply ignores the handheld media type altogether.

Not sure what the error could be on your end—sorry! Was wondering, if you have multiple versions of images which load depending on browser width, are all three images being downloaded even though only the appropriate one is being displayed? If its loading them all, will this not be a problem for page size, especially now google is meant to be using size as a factor is its results? Nice examples, and a compelling argument for a single page. But for a well-featured application or site, it is naive to send the same content and IA to every browser.

Presumably one should rather be designing for the human on the other side? Imagine the perfect airline web site for a desktop user ticket booking, holiday planning, pretty animation of the new flat beds in business class. Now imagine the perfect airline web site for a mobile user on-line checkin, flight status, geo-location, registering for SMS alerts. Thanks a lot Ethan for this well explained article. I must agree with James Pearce though on the content side of things.

For most of the sites we make a responsive layout will not be enough. We need responsive content. But for the more basic websites we will sure going to use your well documented article on how to handle this! I wonder if the criticisms related to the necessity to show different content or functionality as well as better performance could be handled using AJAX where AJAX is supported in conjunction with media queries to provide a more appropriate experience?

Ever since I read this article a few months ago it has stuck with me. I have a couple of question about this method. I work for a popular e-commerce site as a user experience designer.

Recently the engineers in my company have been pushing for us as designers to start incorporating responsive web design concepts into our new projects, referring us back to your article to support their argument.

The problem I run into time and time again is that many of the examples illustrated are of relatively simple layouts where elements, usually similar in nature are repeat and thus can move freely without creating confusion for the user. Elements such as Mini Carts, Buy Boxes, Checkout forms, and other highly complex elements needed to remain locked and clear to a user in order to prevent confusion. My next question is consistency. At my work we know two things, that people almost never resize their browsers once the page loads and that many of our customers will browser our site from one computer but purchase from another, Often these screen resolution do not match each other.

If we present one layout to the user and they go home from work and are presented with another layout on their home computer how does that affect their experience? Any thoughts?

Hope that helps. For more on this, the second and third paragraphs of this comment by Jeffrey Zeldman neatly sum up my thoughts on the topic. Mich , you raise a number of fantastic questions.

I hope that helps, and thanks again. I would like to ad another example that may help or inspire some of you : Juslisen. Thanks to css3 media queries it fits well on small, medium and large screens ie: smartphones, tablets, desktop. What about the markup though?

By scaling images, or using display: none ; the mobile is still loading a hefty site. Where do your draw the line? Thanks for the article. I think things like fluid grids and flexible images are alright for websites, but I think it would be terrible building a decent sized web app with them.

It will certainly be interesting to see how the industry solves these problems. I loved the article, it certainly opened a world of possibilities. Do they? Who are we designing for? The end user or our clients? We have long been taught that people find it difficult to read the width of a broadsheet newspaper, which is why the broadsheet or tabloid for that matter is broken down into bite size columns; i. Usability gurus tell us it hurts the eyes and the brain to have to read across a huge expanse of browser and therefore, we should design for readability.

The human eye finds it more comfortable to read in bite size chunks. So how do we measure the success of a website? The problem I see with fads and fashions is that they are here today and gone next year, or at the very least, they have evolved into another fad or fashion which in turn, is here today and gone next year. I remember when Flash was lauded as, well, the best things since other flashy blinky things, but now, jQuery does the job more efficiently and effectively, and actually gets more respect from search engines for doing it!

Great article Ethan. This is well written with perfect examples. I was particularly happy to see your point about what can be done about increasing the size of the hot spot for links on smaller devices great for touch devices too!

The rest of the digits really have no effect. In Firefox 3. It still works in Chrome…. Otherwise, a designer with no technical experience could create a desktop view and mobile view that are impossible or extremely difficult to implement from the same code, and get that signed off by the client.

This just means design phase would take longer and presumably development phase would be shorter. Anywhere I have worked, design and development have been two separate domains.

For this to work in that kind of environment, close collaboration between designer and developer would be even more important than in the past. Developers would have to teach designers what techniques are possible that could inform their designs. I can only have it as media inside the main style. Firefox for Android Get the customizable mobile browser for Android smartphones.

Firefox Focus Simply private mobile browsing. Privacy Promise Learn how Firefox treats your data with respect. Firefox Blog Read about new Firefox features and ways to stay safe online.

Release Notes Get the details on the latest Firefox updates. Facebook Container Help prevent Facebook from collecting your data outside their site. Pocket Save and discover the best stories from across the web. Mozilla VPN Get protection beyond your browser, on all your devices.

Product Promise Learn how each Firefox product protects and respects your data. Firefox Relay Sign up for new accounts without handing over your email address. Mozilla Foundation Meet the not-for-profit behind Firefox that stands for a better web. Get involved Join the fight for a healthy internet. Careers Work for a mission-driven organization that makes people-first products. Mozilla Blog Learn about Mozilla and the issues that matter to us.

Close Innovation menu Mozilla Hubs Gather in this interactive, online, multi-dimensional social space. There is always a time vs end user experience tradeoff, even with physical goods. I think it's part of a bigger trend towards more prolific crappy stuff generally. I do think there is space for tools that improve the user experience whilst not regressing on easy of development.

There is hope. Elixir's LiveView is similar in my eyes, and more "client-side" tools like Surface akin to Storybook are making their way into the Elixir ecosystem. What is the alternative to catering to developer experience though?

Rather than complain, we should be focusing on making good performance the happy path. In fact, I'd say that's most of what the latest frameworks that are popular focus on, so I don't really understand the issue. If you build the developer experience, they will come. If you don't, I hate to say it, but everyone has mouths to feed.

Aeolun 10 days ago parent prev next [—]. There was plenty to complain about at any point in the development of the web, and complaing about bloated frameworks are simply the complaint du jour.

In practice I load every webpage once even very complicated applications can be loaded in under 2MB , and then go on my merry way. Web development leverages a terrible developer experience to create a terrible user experience. Do you really think the developer experience or user experience were much better in the days of Windows Forms? Or that building large web applications in jquery or vanillajs can't lead to problematic code even when junior developers are used? It's been bleak for a while, but I think we are coming round the bend.

Building a performant Next site that only pulls in the JS it needs is quite doable now. React server side components seem at least interesting here. I still have no experience with them but they do at least claim to tackle some of these issues. As I understand it other frameworks like Svelte and Vue have been exploring these ideas too. I think the bleakness will continue and there will be a long tail of it. But I really do think better websites are coming and in many cases are already here.

I think it's much simpler -- it's about the focus on design over usefulness. I feel the same about iOS apps -- they are all adventure games. And in-place editing on a phone?

Just fill the whole freaking screen with a big editor window in a giant font where I can target the cursor with my fingers, and let me submit it to the field when I'm done. And get off my lawn! PeterWhittaker 10 days ago prev next [—]. My company does complex cloud and on-prem web-based apps, JS front and back.

These inefficient frameworks make our developers more productive and allow us to design, deliver, and fix fast. Storage is cheaper, bandwidth is cheaper, processing cycles are cheaper, all are cheaper than developer time.

And these powerful frameworks give us great speed in iterating new features, which makes our customers happy. The article is too focused on efficient use of computing resources at the expense of ignoring developer costs and customer satisfaction. Then you've certainly run into power users. Chances are browsers can load and display a 2MB server-generated HTML table faster than the DI system in your 5 MB angular app can start all the required services to be ready to launch your pagination component.

Of course I am making this up to illustrate a point. If with this insanely complicated and large array of tools I can't even do better than that faster to implement! That "a bunch of large server-rendered HTML tables" just so often happen to be the previous solution that was in place, and power users are likely to complain if we do worse, is just the cherry on top.

To do better we often have to avoid certain things that would be considered modern. Though obviously people then had to put thought into this stuff and it certainly wasn't automatic.

That includes all the Angular framework, and a component library which includes a data table. Good work then! Your build is half the size of twitch. To be fair they're a video streaming service so they probably don't care about a few extra megabytes here and there, but on lower spec'd hardware you'll feel all that JS: a solid 5s of CPU time just spent executing JavaScript on my thinkpad during that test, not including the time to load it.

And it's not like they're done. If you then do pretty much anything, it'll have to load even more. Apparently if you click a name in chat, it has to load another That's a good bit larger than your entire application! There's operating systems that fit in less than what twitch needs to show a glorified tooltip. On my hardware they could probably boot in that time too. PeterWhittaker 10 days ago root parent prev next [—]. Well, if our apps resembled these large tables of which you speak, maybe….

Most of the screens users see are fairly light. And how quickly we can new things when they realize they need new. I want all my data in a gigantic HTML table, said no user ever reply. I'd love this. I'm a user. I can't think of many examples of software which I use where new features have actually made me happy. Normally it's just change which forces me to learn something new while I'm in the middle of trying to accomplish something actually productive.

I think our industry over-estimates the value of "new features". If—instead of a new feature—the software I used released a performance improvement, then that would actually help make me more productive. PeterWhittaker 10 days ago root parent next [—]. They care about the features in our products and the frameworks we use allow us to do cool fast.

As a JavaScript developer who has been doing this work since before jQuery became popular I sadly agree. It appears there is an arms race to the bottom, as in how low can we lower the bar of acceptability for prospective employment candidates. I can remember back in the day at Travelocity they couldn't hire JavaScript developers to save their business. Its how I became a developer, involuntary reassignment from designer.

This mistake of an application compiled Java to JavaScript for people who probably should not have been writing either. Its all good so long as the code never needs changes or updates at which point Java developers wanted JavaScript developers to fix their obfuscated code.

How hard could writing this rinky dink language possibly be? Back in those days there were some actual challenges, but they were an inch deep and a mile wide. Then, just as now, tree models broke the souls of many software developers. I have never figured this out, because elementary schools are able to explain abstract concepts as tree models to children, but many adults cannot and will never understand the idea on even the most primitive level.

No more walking tree models. Everything is now a chained method or a CSS selector through a very slow Sizzle engine. Now everybody and their dog could add events and text to a web page so long as they could read the jQuery API. In hindsight none of this is surprising in the least. The surprising part is the compensation. Back in the day when the work was hard front-end developers were paid next to nothing. You were much better off being a Java developer where you could barely have a pulse and earn x as much.

As the problems got easier and the number of available candidates blossomed the compensation surprisingly went up Timothycquinn 10 days ago parent next [—]. The developer only used it because he did not now JavaScript and had no desire to learn. It was developed with zero thought into debugging. Needless to say, I punted that app over to another developer to handle as I saw it was going to fail miserably after the first demonstration and my initial questions to the developer.

That project was an abject failure after the company spent hundreds of thousands of dollars at it. The author is correct but not for that farcical reason. Here's some real ones. It encourages the following: A URL that is now less Universal than ever, pointing to an application more than a piece of content Content that is not self contained in a single document so it is hard to archive for the future Content that is not served with the page nor containing a universal reference so it is hard to scrape and catalog A profound inability to inspect websites because they are now transpiled via frameworks and emit something obtuse and only machine, not human readable Content that is now in a non-generalized method of access so instrumenting it to fit it for different purposes the "Free" part of "information is meant to be free" is now fragile and dubious And more controversial: The careful separation of concerns of the Javascript Controller , HTML Model , and CSS View gets tossed together and entangled in a single stream of hybrid languages where they no longer are separated.

Instead people rely on less rigorously made tools to achieve the same ends with increased difficulty, less reliability, and less functionality - all cost and no benefit. Swizec 10 days ago parent next [—]. As someone working on an actual webapp Total transfer size around 5MB. Links to individual pages would be useless to archive because they're not documents.

Kinda like "Why would you bookmark a individual app window? You can right click inspect or use react devtools, which is nice if you're trying to understand things.

That part is way more accessible than an equivalent iOS, Android, or Desktop app would be. Oh and we don't need to build an iOS, Android, and Desktop app! It's a single webapp that works in any client of your choosing. Plus you get fresh updates and bugfixes with every page load, no delayed update cycle.

This may be controversial if you dislike a UX change we make. This is also the setting where code is most likely to be understood, as understanding a codebase is very hard.

Sharing code is not just a matter of dumping original source code to the public, and I think the use case around ordinary users examining source code is very, very niche. And how should compiled-language communities like Rust handle the issue of sharing code?

Should they distribute the original source code with the expectation that their users shall compile on their end? Is that the right way to share code, or is that just dumping code to the public?

I don't think it's ordinary users examining the code. The issue is develops figuring out bugs in their own projects. You try to trace why one thing isn't working and after many hours of digging through things in developer tools you realize two or more of the massive JS libraries someone needed to import for a single function doesn't work with another in a specific use case.

Fairly basic websites today are importing hundreds of thousands of lines of unnecessary code to achieve rather basic functionality. The argument comes more from the RMS argument of distrust; people should have the liberty to inspect the mechanics of the systems they wish to use in a way that isn't willfully obstructed.

Yes, there's holes in that argument you don't get to inspect the server side code for instance , but it's a statement from principle. The web was intended to be an open platform in that "I'm free to inspect and repurpose within reason" kind of way. The radical philosophy and promise of the web and open source has been sublimated and replaced with a cynical variation, a form of elite pirate capitalism. If "we shape our buildings and afterwards our buildings shape us.

This article is no longer correct as 'cache partitioning' in modern browsers stops CDN assets being reusable for different sites in cache. In my opinion the solution was always progressive enhancement, but things went crazy with JavaScript: The Good Parts and especially Node. It can be enhanced with a Makefile but for now it's simple enough. I don't believe static site generation is a JavaScript job, and to be honest, I don't believe JavaScript belongs on the server side.

This doesn't line up with my experience. IME these are the major drivers of web "slowness" for different types of sites: 1 Client-side-rendered apps that haven't embraced hydration of pre-rendered HTML suffer for it.

Not because the JS is necessarily too large, but because it blocks the content from being visible. This would be bad even with a small bundle. Luckily this is an easy problem to solve today, but not every site has done so. I've seen sites with I kid you not several times the amount of marketing JS by weight as they have actual functionality-giving JS.

The actual devs often don't even have control over these scripts thanks to Google Tag Manager , and even if they do they probably don't have a say in what can be removed. You're not optimizing for first-visit, you're optimizing for responsive interactions. This has even less to do with bundle size, and often not even much to do with JS itself. The biggest thing is, as professional web developers, we have a responsibility to the end user to make a web page load fast and be usable quickly, and I think we often over-look that.

The flip side is, most clients just want their project done quickly so they can make money. Personally, I like building without extra build tools. I really want a batteries included standard browser library. There is also a strong argument that the web is much better today because of modern frameworks and technologies. The web has shifted from being a place for basic content and documents to a full-blown application platform.

Today, many popular applications can be used in the browser on any device and any operating system. Examples like full office suites including MS office and Google docs, or photo editing apps, or music streaming platforms, or video conferencing. I would argue that this advancement would not have happened without frameworks.

Or at the very least, it brought about frameworks. Since the web platform itself is not designed for applications, any large application will probably end up writing some sort of abstraction on DOM rendering and state management, just to make it halfway maintainable. So if we want web applications, which are very beneficial in many circumstances, frameworks and tooling are a part of that.