Pretty printing code on mobile

[Dani]

Before anyone files a bug report, we are no longer pretty printing (using javascript to add line numbers & color coding) code snippets when on mobile browsers for performance reasons. It's not that it was particularly non-performant on mobile. It's rather just that I'm working hard to improve performance across a variety of devices, and I felt like it wasn't worth the trade-off, given it's an extra second or so of javascript parsing in exchange for making code not all that much more readable when on a mobile device.

[JamesCherrill]

I guess you have never heard of something called an "iPad", let alone the "iPad Pro". The screens on these beasts are better than on most PCs.
Some of us have moved on from computers that need a trolly with wheels to be moved.
It's alomost 2020... what are the "other devices" that are so much more important than the mobile devices that represent the majority of the market?

[Dani]

My apologies for the confusion. When I said mobile browsers, I was referring exclusively to mobile, and not tablet, devices.

[Dani]

Hmm ... it looks as if highlighting code has been disabled on iPads in portrait mode and older generation iPads due to the horizontal screen resolution being < 1024. Browsers with at least 1024px of playing room should not be affected.

Also, yes, the latest generation of iPads use a Retina display to pack in lots of pixels. Unfortunately, these pixels are just used to make images and the UI crisper and don’t actually give your apps any additional working space.

[Dani]

That being said, the reason for the shift was not really due to screen constraints. While that was enough to consider the trade-off worth it, the primary benefit is that wireless devices tend to not always be connected to WiFi and therefore downloading and parsing such large JavaScript files significantly reduces page timings.

This is actually the reason Stack Overflow doesn’t highlight their code at all, on any browser.

I’m trying to stay as competitive as possible, and they don’t do it at all for a very good reason. The small bit I’ve been able to cut back on page speed has been having dramatic effects on our performance.

[JamesCherrill]

wireless devices tend to not always be connected to WiFi and therefore downloading and parsing such large JavaScript files significantly reduces page timings.

Don't know who your mobile supplier is, but here in the wilds of rural France my iPhone gets >50M/sec download most of the time, vs the 20 I get from my landline-based WiFi at home.
That having been said, I've never seen any speed problem downloading or rendering DaniWeb on any device.
To the best of my knowledge there has never been an iPad with <1024 pixels.
Why does pretty printing not all that much more readable on retina screens but it does on lower-res screens?
And why do you think pads are not "mobile devices" - is it because they don't have cellular comms or because they are too big and heavy to move???
Sorry, but your view of mobile devices just makes no sense to me.
(I seem to remember a while back that you were not interested in making the post editor work properly on tablets - maybe you just have a thing against them?)

Anyway: What does matter is that without line numbers it's really hard to refer to code that's more than a few dozen lines long.

[Dani]

Don't know who your mobile supplier is, but here in the wilds of rural France my iPhone gets >50M/sec download most of the time, vs the 20 I get from my landline-based WiFi at home.

I have gigabit Internet and dual 5K monitors. But I can't design DaniWeb for what I have. Google Analytics as well as Google Search Console track page timings for visitors who use Chrome. The results of that data plays a huge role in SEO. Google's algorithm cares almost exclusively about how fast your site is on mobile devices, and not desktop. Any improvements to mobile are a huge win.

To see a glimpse into this data, check out: https://developers.google.com/speed/pagespeed/insights/

By removing prettyprinted code from mobile devices, I was able to increase our Mobile score from the lower end of the "Slow" category all the way to the "Medium" category.

It's not just SEO though. The dramatic increase in page speed has very strong correlations to lowering bounce rate and increasing time on site. It's important for us to remain competitive, and there is a strong reason why Stack Overflow does not highlight their code regardless of device.

That having been said, I've never seen any speed problem downloading or rendering DaniWeb on any device.

There are three reasons for that. Firstly, it's because the majority of files required to render DaniWeb have already been cached by your web browser as you navigate between pages. Obviously that isn't the case for people who enter DaniWeb as the result of a Google search. Secondly, it's because you know what DaniWeb is and so when you consciously browse to a URL on DaniWeb and wait for it to load, your brain doesn't care about the extra 500ms.

Check out this article on Kissmetrics, for example: https://neilpatel.com/blog/loading-time/

It says that 47% of people expect a web page to load in 2 seconds or less, and 40% abandon a website that takes more than 3 seconds to load. Removing pretty printed code reduced our average page load time from 4 seconds all the way down to 2.7 seconds for mobile users.

Check out this article which has suggested that Amazon reduced their page load speed by 1 second and it resulted in an extra billion dollars of revenue.

https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales

The third reason why you have never seen any speed problem with DaniWeb is because you are not our typical user. The average DaniWeb user is in India, where Internet isn't nearly as fast as it is in developed countries.

To the best of my knowledge there has never been an iPad with <1024 pixels.

Yes, iPads typically boast they have a minimum of 1024 pixels. However, keep in mind that the screen size of the iPad Mini, Air, and Pro have a screen resolution of 1024x703, which means that only one dimension is at least 1024 pixels. That means that you should be able to see prettyprinted code on DaniWeb when the page is loaded in landscape format but not when your iPad is being held up in portrait format. It is only the large iPad pro has a screen resolution of 1366x1024.

Why does pretty printing not all that much more readable on retina screens but it does on lower-res screens?

As mentioned in my previous post, even though Retina screens might have a whopping 4K of pixels squished in there, the point of retina is not to fit more content on the screen. It's to make images and UI elements look crisper and cleaner and higher resolution. This does not translate to the physical size of UI elements. In other words, whether you are using a retina screen for an iPad Pro, an iPad Mini, or a first generation iPad, you're still going to have the exact same 1024x703 pixels of screen real estate.

And why do you think pads are not "mobile devices" - is it because they don't have cellular comms or because they are too big and heavy to move???

For the purposes of front-end web development, my definition of a mobile device tends to be devices with < 1024 pixels to work with. iPads are kinda on the cusp there because they meet the criteria when being held in landscape mode but they don't when oriented in portrait mode.

(I seem to remember a while back that you were not interested in making the post editor work properly on tablets - maybe you just have a thing against them?)

Our editor requires a lot of heavy Javascript in order to function, and it came down to page load speed there as well. Additionally, the third-party code editor that we use is simply not browser friendly, and rather buggy, across most mobile browsers. It made more sense to save a few seconds on page load time and not present the user with a buggy experience to boot.

[Dani]

I want to also mention that it isn’t that I have anything against tablets as a form factor. Microsoft Surface tablets that have the exact same form factor as iPads are fine.

My issue is that while the Surface runs full blown Windows, the iPad runs iOS, which is designed primarily for phones. Mobile Safari is nowhere near as robust as desktop Safari, and are impossibly harder to write for from a web dev perspective. If iPads ran desktop Safari, that would be something else entirely.

[JamesCherrill]

iPads now run iPadOS, not iPhone IOS. As you may guess it's optimised for the tablet screen sizes.

According to Apple the iPad Pro series run desktop Safari. I use a pro and MacOS and haven't seen any differences.

[Dani]

iPads now run iPadOS, not iPhone IOS. As you may guess it's optimised for the tablet screen sizes.

I watched the complete WWDC keynote where iPadOS was introduced on announcement day, and the UI is more optimized for tablet screen sizes and use cases than iOS is, for sure. However, it still leaves a lot to be desired compared to the desktop versions of apps.

According to Apple the iPad Pro series run desktop Safari.

I was not aware that the recent version of iPadOS was running desktop Safari. I just did a Google search and it does, indeed, seem as if the desktop rendering engine was introduced to the iPad on September 24th. However, there are a few things to consider here. Firstly, that was less than 2 months ago. Secondly, the iOS version of Safari is extraordinarily limited from a browser technology / web developer's perspective. On a site like DaniWeb, with a worldwide audience using a wide variety of browsers and technologies, you cannot design it just for the very latest browsers.

For example, my ability to use responsive design to make the site functional for all different form factors is exclusively based on browser pixel width. At the same time, I want to create something that is as usable as possible to the most people using devices at that width. I cannot assume that the very vast majority of users with 1024px pixel browsers accessing DaniWeb are using the large sized iPad Pro (not even the standard sized iPad Pro) and have had it updated within the past 2 months to the latest version of iPadOS. Adoption rates for new technology is slow!

However, there's something much more important to consider here, as well. While iPadOS might be converging with Desktop Safari in terms of their rendering engine, that does not fix its limitations from a web developer's perspective. It still doesn't include developer tools which allow me to explore the DOM to diagnose and fix any bugs, the way I do with every other web browser I test in. iPadOS still does not have mouse cursor support, which is an extremely limiting factor. Javascript toolkits such as what powers our editor, for example, are huge third-party libraries that have been hardcoded specifically to work with a keyboard and mouse, and they are incredibly buggy (or don't work at all) with touch support. The same can be said for most of the javascript libraries we use, in which separate touch-support would be needed before they can be used.

[Dani]

I'll mention there is Chrome for iPad as well.

There is, and I use it much to my boyfriend's chagrin. However, it still suffers from all the same limitations as mobile Safari.

As a web developer, I can't inspect the DOM with the built-in developer tools functionality. I don't have any of the tools I need to diagnose or fix bugs. It's missing many basic plug-ins. It relies on touch support instead of mouse support, which requires an entirely separate set of basic Javascript libraries. I can't use third-party browser extensions such as SEO extensions, that I rely on to test my work. Many third-party frameworks, such as what we use for our editor, are entirely unsupported. I can't enable/disable ad-block to ensure everything isn't broken for the many users who use ad-block. In conclusion, testing from a mobile browser (which includes iPadOS browsers!) is akin to writing a very intricate software application, and trying to diagnose bugs just from looking at screenshots of the final product but not being able to interact with it at all.

The biggest pain points in this discussion seem to be the loss of prettyprint and the editor not working on iPad devices. With regards to the editor, the Javascript framework we use simply does not have touch support. That means that if you're using an iPad and you try to tap somewhere in the editor textbox to begin typing, the editor won't recognize your tap in the same way as it would recognize taking a mouse cursor and clicking. That makes using the editor textbox a moot point.

When it comes to the loss of prettyprint, it was done for the absolutely huge performance gains, both in terms of mobile devices having slower network connections as well as mobile browsers simply not being able to render as efficiently as desktop browsers. For the purposes of prettyprint, I define a mobile browser as anything with < 1024 horizontal browser pixels, and most iPads fall into that category. While the largest iPad Pro does meet the 1024px width criteria, it still suffers from the rendering slowness.

[rproffitt]

Thanks Dani for the rundown of Chrome on the iPad.

Here it's been a hit since my brother wanted a workaround to some sites which are mostly about insurance that didn't work on the iPhone or iPad. I mentioned he should try Chrome and the next day he reported all was working so to me this is a valid fix to some sites that didn't work on these devices.

As a developer I would find such omissions disturbing. But for the users they just want the site to work and as you pointed out above, changes are done for reasons.

This also reminds me of this XKCD https://www.explainxkcd.com/wiki/index.php/869:_Server_Attention_Span where you try to get the normal page and the server is adament to serve up the mobile version.

[Dani]

rproffitt,

To your point, I think it would be disasterous to follow in the footsteps of that insurance website and have something that doesn't work in Safari but works in Chrome on your brother's iPad. I have no control over what browsers people choose to use, and requiring them to download a third-party Google browser just to make DaniWeb usable is not a good experience -- in fact, it's not even a mediocre experience. I don't think anyone would get that far ... they'd wind up at DaniWeb as the result of a Google search, have a subpar experience, and leave forever with a bad taste in their mouth. It makes much more sense to me to provide a good experience with a limited set of DaniWeb features (designed for a < 1024px resolution, limited browser capabilities, assumption of slower network connection, complete touch support, etc.) , than a slow, buggy experience and a cramped screen with all DaniWeb features.

[Dani]

... and, dare I say, if you want a full desktop experience in a mobile form factor, get a Microsoft Surface tablet, a Google Pixelbook, a 12" MacBook Air, etc. In other words, it's possible to reproduce the iPad's form factor but with a desktop operating system that has mouse support and the ability to run full versions of desktop apps.

By using an iPad, you're trading in full desktop functionality, and with that, full browser functionality, for instant boot-up, no need to carry around a mouse/keyboard, one handed touch usage, and all of the ease and simplicity of a slimmed down interface. Unfortunately, websites don't understand touch gestures without a lot of mobile-specific javascript, and your slimmed down interface is, just that, slimmed down.

[rproffitt]

I feel I should share that for my brother who runs an insurance business that telling staff, users and who else to try Chrome has resulted in thank you's as folk can now get it done. We have no hope these companies will fix it to work on last year's Safari (this was when this issue came up) so we have a great solution which no one has said "not a good experience."

[Dani]

It’s different when you have a word of mouth business with a smaller set of end-users who require access to a web-based tool. Your brother is in the position to tell people using the website that they would have a better experience if they used Chrome, which they do, and so they’re happy, because they needed to use the site to do their jobs.

That obviously isn’t the case with a site like DaniWeb, where random people from across the globe come in from a Google search, and develop first impressions and whether or not they’re going to bother with the website entirely within the first second of load time. If it’s not a great first page load, they’re off to a competitor within those first 3 seconds and we lost them. Unfortunately, for us it’s the case that, according to Google Analytics, the average visitor across all our traffic spends 47 seconds on DaniWeb. This average factors in all the regulars who spend hours, so you could just imagine how many people spend less than 5 seconds to balance out to 47s. Our number one priority is to load as fast as possible and as bug free as possible in those first few seconds we have to capture the end-user’s attention before they’re off somewhere else.

[rproffitt]

Just checked out daniweb.com on my Moto smartphone which BTW has Chrome as it's default browser. DW came up just fine and thank you for pushing the big advert off the top of the screen. Otherwise it would have been just a few items then something about Sprint.

About Sprint. Horrid experience there. I had moved from Boston to here and since we were using Sprint for the carrier of our GPS tracker solution (school buses and such) I setup Sprint as my carrier only to find out the coverage at home was 1 bar to none. Even outside.

Now you think I would have bailed but this was used to our advantage as we worked on how the product performed as coverage went in and out of range to low quality connections. I could see all this from my office without having to hit the road.

Later we met with Sprint about many things and I asked about coverage near me. My neighbor had told me Sprint removed a tower in the area which the engineer confirmed so this lead to checking out other areas where our clients were asking about long delays on the GPS location reports. Sure enough, same story.

You can bet that I personally won't reccomend Sprint or any of its MVnOs.

Time passes, the product development is done and I go with a T-Mobile MVNO. Much better. Also, ATT and it's MVNOs are better but hey, Ting.com works for us.

[Dani]

What about now that T-mobile and Sprint are merging? From my understanding, the T-mobile CEO will be stepping down after the merger.

[Dani]

Also you can donate to DaniWeb and not see any ads :)

[rproffitt]

You would think I'd do that but then I would not have the everyperson experience. So as a moderator I have to see what others see with a spare account which I do now. But pay and I see even less so without a toggle of ads on/off it's better to have ads on. I do not want to ask for toggles to show, not show this or that but maintain the home page is a lost opportunity.

In other words, if I pay I miss out on what others may yelp at.

[JamesCherrill]

(just for the record, I've not stopped posting because I've been convinced. I've stopped posting because I'm wasting my time)

[Dani]

(just for the record, I've not stopped posting because I've been convinced. I've stopped posting because I'm wasting my time)

I think it's a matter of our goals being misaligned. Your goal is to receive the best possible experience given your specific device, network connection, and use case. My goal is to provide the best possible experience for the largest percentage of users, with the acceptance that fringe cases are going to be unfortunate casualties.

[Dani]

with the acceptance that fringe cases are going to be unfortunate casualties.

For my goals, someone using the latest version of iPadOS with a large iPad Pro, and genuinely missing line numbers when in portrait mode, is an edge case that most likely affects fewer than 3 users. If I could provide such huge speed improvements that Google has moved us from the slow to the medium category, and as a result, we have a 100% increase in visitors compared to this time 3 months ago, then giving up line numbers for 3 visitors is an acceptable loss for me. It's not for you, because you're one of those 3 users.

[Dani]

is an acceptable loss for me. It's not for you, because you're one of those 3 users.

Something that does cross my mind a lot is when I try to design for the masses, and the casualties of the edge cases end up being the more long time users or the users who contribute the most to DaniWeb. I certainly don't take the decision lightly, but there is a trade-off when it comes to is this one visitor losing this one bit of functionality equal to gaining an additional 100 visitors a month? Making the experience better for 10,000 other visitors? How about making it a worse experience for 5 DaniWeb regulars in exchange for making it a significantly better experience for 500 DaniWeb newbies?

From there, I try to use as many analytics tools at my disposal to try to figure out what the gains and losses will be. For example, if you keep your line numbers available on your tablet, will you eventually grow discouraged with DaniWeb's low activity levels and leave within a short time period anyways? But will getting rid of line numbers bring in 5,000 additional users in which 2 of them will go on to become DaniWeb regulars over the next few years?

I'm not trying to say that you're an acceptable loss. I'm just trying to put into perspective how everything seems to be a very delicate balance, and I'm trying to do what I think is right for the long term goals of the site. When casualties end up being those who contribute the most, it's definitely always a very tough decision, and never one taken lightly.

I definitely used to jump through more hoops to try to do my absolute best to accomidate the regulars, even if it was to the detriment of the newbies. But what I learned over the years is that the issues that regulars tend to complain about are really just the straw that broke the camel's back, and not any single issue is going to be the deciding factor whether they stick around in the long term or not. I'll jump through hoops, and make this particular user a priority to the detriment of more than 10,000 newbies or first-timers, and then they'll end up leaving anyways, either because our activity levels are too low, or they went on to focus on other interests in their life. What I learned was that isn't a way to sustain a business like a forum where there's constant churn and bringing in new blood is consistently important.

[Dani]

Just trying to give you some ideas as to where my head's at when I'm making these kinds of decisions. It's definitely not something to take lightly when JamesCherrill says that line numbers on his tablet make or break his using of the site.

[JamesCherrill]

JamesCherrill says that line numbers on his tablet make or break his using of the site.

Lie. I never said that.

[Dani]

My understanding was that line numbers being removed from mobile devices is a contributing factor to it being difficult for you to help people with code. Perhaps I over-extrapolated?

[JamesCherrill]

"over extrapolated" ... a worthy sibling to"mis-spoke".

Don't worry, this is the post-truth age of Trump and Boris. Your 10,000 other visitors or newbies can join the unprecedented millions at Trump's inauguration.

None of this matters. DaniWeb is dead, has been for years, and you don't have the technical resources or marketing muscle to revive it.

Looking at the posting activity you, rproffitt, and I may be the only active remanents of the cohorts who enjoyed the forum-based pre-Dazaster days. Fond memories. Time to move on. That's life.

[Reverend Jim]

Looking at the posting activity you, rproffitt, and I may be the only active remanents

Ahem...

[JamesCherrill]

Sorry Rev Jim. My bad.
JC