I want to serve the same DOM to all browsers and devices, e.g. desktop, tablet, phone, etc. However, I do not want the assets (images, stylesheets, etc.) intended only for desktop to be downloaded on mobile and waste HTTP requests and bandwidth.
Is there any way to manipulate the DOM before the browser starts downloading the assets, using strictly client-side Javacript, depending on the device and browser?
I feel like using the DOMContentLoaded event (https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded) gets me close..
EDIT: I have found that mobify.js seemingly does what I am after: https://www.mobify.com/mobifyjs/v2/docs/
They provide a 'Capturing API for manipulating the DOM before any resources have loaded'. It also appears to be done with client-side Javascript. Will have to look through their source on GitHub to see how they are doing it.
One easy option to send device appropriate images is adaptive images. It will resize the images based on break points you set, and on your visitors' screen size.
What I particularly like about this specific solution is that it's also easy to instal to an existing site. You can try it out and if it's a good fit for your site then you are off.
There are some JS techniques to send different CSS files based on screensize or viewport. I have used one in the past, but FWIW I've found that if you minimize and compress your CSS files, there's little be gained and it only adds a layer of complexity. Your time is much better spent trying to save bandwidth on your images.
EDIT
Another possibility that might might work well for you is the newer srcset attribute, a couple of links to get you started:
http://css-tricks.com/video-screencasts/133-figuring-responsive-images/
http://martinwolf.org/2014/05/07/the-new-srcset-and-sizes-explained/
Good luck!
The only thing I could think about it is kinda naive and implies the use of "document.write" to include the "img" tags just for desktop connections. However, you also point that you want the same DOM for all devices, whereas there will be javascript elements in this case. Unfortunately you don't want to do it from server side which would be easier and clean.
Related
I have a static site and I want to show some PDFs. The PDFs range from 6MB to 55MB. I was wondering what would be the best way to embed PDFs, in terms of loading speed, interface etc.
If there’s a solution that makes it possible for viewers to continue where they left off after they leave the site and come back, that would be nice to have, although I don't think I can code something similar myself, especially since the site is static.
A nice, lightweight option that requires no extra dependencies is the embed element. It’s built into the HTML spec, so you’ll enjoy pretty good support. I’ve used this in a project of mine where I need to display lots of on-the-fly rendered PDFs. (See project here of you’d like an example.)
From what I’ve seen, the embed element works pretty well on both desktop and mobile.
Do note that different browsers will display the PDF in slightly different styles. Firefox, for instance, will just download the PDF if the user has PDFs set to auto-download in Settings > Application. I think there’s a library called PDF.js that can give you more consistent results if you need really fine control over the PDF display.
I am new to mobile web development and I'm trying to figure out the best structure. I have decided to use a sub domain to handle everything mobile with some JavaScript that points to that sub domain if it detects mobile.
My JavaScript file points to http://m.mywebsite.com. The sub domain is on the server at "root/mobile" so all the resources are mobile use can be grabbed there.
Here is my confusion: To use less resources and data, duplicate files I go back a directory. For example, to embed the logo image I would use src="../images/logo.png". Wouldn't this be correct? Is there any disadvantages to doing this? I don't see a point in make a new images directory and placing a copy of the logo in there as it would use more data. Although, everywhere I look online people are making duplicate directories inside their mobile directory.
Perhaps it doesn't matter and I'm overthinking this. Or perhaps I'm looking in the wrong places... if this is the case, can someone provide useful links for starting out mobile use?
Thank you!!
I hope I get you right.
Whether or not the general (not mobile) resources folder is in different domain/subdomain, you can, to be on the safe side, refer to that folder by specifying the full URL (as long as the client has access to it. see CORS), rather than the relative URL.
src="http://m.mywebsite.com/images/logo.png"
src="http://m.mywebsite.com/mobile/images/logo.png"
src="http://mywebsite.com/images/logo.png"
Regarding images duplication, it is preferred to use smaller resolution copies of your desktop images for mobile versions. Smaller images result in better scaling on smaller screens and better latency (as the files are smaller in size for download).
So if you use smaller images for mobile version, you have no duplication anyway.
Take into consideraion that mostly storage costs are much cheaper than network traffic costs. So it is mostly better to have an appropriate resource for every relevant case, than to worry about one more or less directory.
Our goal is to let a person, similarly to how you can embed a youtube video, embed a tree of web pages on our SaaS into their own site.
The solution should be good looking, cross-browser, responsive and simple for the end user (ideally, should be search-bot friendly as well).
We are considering two primary options where the customer only needs to copy+paste a code snippet which supports embedding in a portion of the page (ex: the middle column) or full width (ex: everything under a header):
IFRAME: Let the user embed an iframe inside a div, together with a snippet of JS that would resize the iframe as the window is resized.
JS "APP": Let the user paste in a script tag to a JS script/app which would communicate cross-domain (via CORS or JSONP) with our servers.
Ideally, we would like to be able to launch full screen modals from our content.
Questions/concerns for:
IFRAME:
Can an iframe reliably update the URL of the parent’s browser window?
Can we reliably launch full screen modals from an iframe?
Can we reliably get the iframe to resize when the window is resized or iframe content changes?
JS "APP":
How significant is the overhead of dealing with properly encapsulating our app to avoid naming/library conflicts? For example, we will ideally stick to vanilla JS but if we want to use a library like Ember and a customer of ours has an Ember site.
Any non-obvious cross domain gotchas? We will be using CORS or JSONP.
We would like input on both the:
technical limitations of what’s possible to do
practical hurdles we’d have to overcome going down each path.
p.s. We’re also considering a back-up option, which is to “fake” integration, where we host the content on our site with a subdomain URL (similarly to how Tumblr lets people host their blog on something like “apple.tumblr.com”). If we go down this path we imagine letting the user theme the subdomain. We understand the pros and cons of this path. Downsides are, it’s more work for the user, and they need to keep two different sites in sync visually.
I think the best approach is to use the same approach Google and other big companies have been using for quite some time, the embedded script. It is way better looking and semantically unharmful (as an iframe could - arguably - be), and super cross-browser and simple, in fact, just as cross-browser and simple as the code that will be pushed (it can be recommended to be put in a <script async> tag, which will eliminate the need for a crafted async script and, though it won't be as full compatible, it degrades okay and will work very well on most cases).
As to the CORS, if basic cautions are taken, there's no need to worry a lot about it. I would say, though, that if you're planning to do something in Ember or Angular to be embedded, that may be a whole load of scripts/bytes that can even slow down the site/app and impact on the whole user experience, perhaps too much for a component that would be loaded like that. So whenever possible, vanilla JS should always be used in components, especially if Ember/Angular is used because of specific features like binding (specific vanilla JS codes can cover that with much less weight).
I'm displaying a bar code on a web page and wondering if there is any disadvantage using JavaScript to do it rather than an image or pdf in terms of caching?
Caching will most likely be applied on scripts and images, so in that case there shouldn't be much difference. However, I think your image will change every now and then showing a different bar code? In that case a script that generated the code can have the advantage because the generation code never changes and will stay cached while the differing images must be downloaded again.
Javascript can be cached if it's in an external file, so go for it. Recognise however, that some browsers have Javascript disabled, it's probably more % of users than you would think with the popularity of plugins such as NoScript.
The advantage of an image is it will work on far far more browsers (100%). It can also be saved, if this is something visitors might do. Saving the output of a JS file is a little trickier for end users.
So I would favour an image, unless you are generating hundreds of new barcodes and have a solution in JS that makes that job a lot easier.
Cliffnotes: It depends on your situation. But hopefully I've outlined the most important pros/cons.
Any code you 'produce' via javascript cannot be cached
If you are using javascript to load an image or some other document then it will be cached.
I'm trying to wrap my head around jQuery Mobile. My aim is to build a very fast application with a look and feel as close as possible to a native app (at least for modern devices).
I understand there are two ways of navigating between pages:
Loading each page as a separate page and linking to other pages with regular html anchors.
Putting all (or many) pages on one single web page and navigating between them by means of javascript ($.mobile.changePage (method) and similar api functions.
The first approach should work on all browsers, but performs quite poorly since there is a delay between each page transition.
The second looks like it should be much faster, so I would definitely prefer this approach. But how would that work for mobile device browsers without javascript support? It certainly seems to violate jQuery Mobile's aim to provide a gracefully degraded experience for C-grade browsers.
It looks to me like I need to implement my app twice, once optimized for browsers with javascript support, once for browsers without? Using may be another option, but that looks even more messy.
What's the recommended way to approach this dilemma? Is there anything I have not noticed?
Thanks,
Adrian
First of all: Your point2 is wrong.
See Local, internal linked "pages" in here and read it carefully. A link href="#pageelementid" will work just fine AND will work in any HTML4 capable browser too [might require <a name="pageelementid"> in some cases, I'm not sure anymore] with the only difference being that all the pages are visible at once.
Second thing is that if you use the way number 1 it will look quite nice too. It will load, yes, but in javascript-enabled browsers it's loaded with AJAX and there's no nasty blink between pages. Also - a "loading" popup shows up.
jQuery Mobile is supposed to let you create an application with some pure and simple html without any JS. JQM itself takes on the enhancement of the page so that it looks good and uses AJAX. Try to create an application that would work in every browser possible (my inspiration: lynx) and use JQM markup for that. Any javascript you are willing to write should work as an enhancement - making it better instead of making it work at all.
good luck with that!
The current thinking on supporting lesser browsers is to not degrade gracefully, but to enhance. If you build the website from the ground up to work without javascript then enhance it afterwards, then you pretty much know that the site will work (rather than having to fix it or build a secondary site).
As regards the two options you've specified, number one would be my preference as a mobile user if I had a limited bandwidth and also a lot of people have a restricted download amount per month.
Lumping all the pages into one large file may seem like a good idea (downloaded already), but you may well run into memory limitations on certain phones. And what if all they want to do is visit two pages, why should they be forced to download the entire website to do so?