As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In my phonegap/jquery mobile app, the multi page model is been used.
index.html have all the pages of my app, so far 6 pages .
If this app would grow too much and it turned to be 19 pages in a single html file, would it be bad?
I created other app to test and used one html file to each page. But looks like every time the page is changed, the whole DOM is loaded again, is that right?
Please tell me which structure is better for a big app
When working with jQuery Mobile first thing to think about is what kind of page template should I use. I have already talk a little bit about this topic in one of my previous ARTICLES and now I have a need to clarify this part of a story a little bit more.
To make a story short (I am not going to talk about page architecture, everything you need to know can be found in a previous link). This answer can also be found on THIS location, to be transparent it is my personal blog.
Multi HTML page template:
This is a template where one jQuery Mobile page is placed inside a single HTML page.
Good
Smaller and lighter, each data-role="page" is inside a separate HTML file and page structure is much more modular.
Can become even smaller if every subsequent HTML page is stripped from HEAD content, or anything that isn't data-role="pšage" div. Unfortunately in this case fallback if JavaScript is not supported is out of question.
DOM size is relatively small, only first page is permanently loaded into the DOM, any other page will also be loaded into the DOM but at the same time it will also be removed when not used actively, basically each time you move from it.
Better fallback if JavaScript is not supported. Works great in desktop browsers after a page refresh, mainly because every HTML page has an existing HEAD content. This also allows your app to behave like normal web app mainly because AJAX can be turned off.
...vs the bad
Consumes more bandwidth as each page navigation generates a new request. When moved from every page will be permanently removed from the DOM, unless cashing is turned on.
Navigating back to a previously loaded page will again generate a fresh request.
Initial page load is fast but subsequent page loads are slower then in multipage template. This can cause problems during page transitions, more so on mobile devices. Desktop browsers don't have this problem.
Much more suitable for desktop browsers then mobile browsers. Also suitable for larger applications, again this is problem for mobile devices.
Pageinit event will be triggered each time page is visited (for those who don't know this an event that replaces document ready in jQuery Mobile and thus it should run only once), which consequently causes problems with multiple event binding.
Can't use more then one data-role="page" inside any subsequent HTML page, only initial one can have more then one page.
Multipage template
This is a template where one or more jQuery Mobile pages are part of a single HTML file.
Good
Since all pages are already loaded, no additional requests are generated for navigating between pages.
First load is slower as the file size is larger, but subsequent page navigation is fast, thus making transitions much more smooth. Almost native like smooth, emphasize on almost.
Suitable for relatively smaller applications and situations where you know the capabilities of your target platforms including presence of JavaScript support, thus making it a great solution for a hybrid app. It works much much better as a Phonegap app then multi HTML template.
The "page" data-role element is required.
...vs the bad
Heavier. All the pages are in a single html file. Large applications with many pages will increase the DOM size.
Needs JavaScript support as Ajax Navigation is used.
Multiple page containers are present, and only the first one is shown when page loads.
Using data-ajax="false" for internal pages ignores the data-transition attribute, by default slide is used
Heavily styled pages can become sluggish on mobile devices.
In the end, the secret of a good jQuery Mobile page architecture is somewhere in the middle.
Your code will be easier to maintain and update if you break each page into its own html file.
Sometimes you want to animate between every page, or have an input form that has the illusion of being multiple pages but is in fact multiple divs on the same page. In these and many other cases, using one page has distinct advantages. If you have no real need for that kind of functionality, though, break apart your site.
Related
I'm trying to make a web page that is single page, doesn't scroll; IE, takes up the whole width/height of the browser size the user has.
It will have buttons/navigation on the top or bottom.
So when the user click on the "contact" page, it will show up instead of the regular "home" intro page, likewise with the other pages without loading to a new url/page.
Does this make sense?
Similar to this.
https://itmeo.com/brut-premium-wordpress-theme/live/#!
I'm wondering if this is possible, if so, would JavaScript be beneficial in creating a site like this or would another language better fit this project?
I suggest that you should read more about AJAX.
SPA or "single-page application" have a havier usage of ajax. and also take time to read about Developing cross-browser and cross-platform pages to avoid inconsistency and issues on the design part.
I have some html content that gets embedded into a page via a server side call. So, when the page's html is being compiled on the server, a call is made to another server to return some html, which is then embedded within a div somewhere in the body. The problem is, this content contains it's own css. So, I wrote a script to inject style tags into the HEAD on ready, which works fine on desktop browsers. However, on mobile devices there's a fairly significant flash of unstyled content. I know that you're technically not supposed to include style tags in the body, but in this case would it yield better results to just include them in the body instead of injecting them into the head?
In this case, it sounds like the right solution is to fix up your architecture so that the server-side compiler can include CSS for the remote page in the page head. This probably involves separating the CSS of the remote page(s) out of the markup there and then grabbing it as a separate file to be included in the page head during compilation.
Since the right solution is not always feasible given a myriad reasons, compromise is often required. Leaving the CSS in the remote markup, if it produces the result you desire, could be the best solution for you. Or perhaps some other hack to get the CSS into the head server-side could be appropriate. You need to decide if it is worth the effort to do any of these things, if they are possible for you to accomplish given your constraints.
Some discussion here. In my experience a lot of enterprise content does it. Does that mean it's the RIGHT thing to do? I dont know. But it's certainly not frowned upon in my experience.
Source: https://www.w3.org/wiki/The_web_standards_model_-_HTML_CSS_and_JavaScript
Why separate?
Efficiency of code: The larger your files are, the longer they will take to download, and the more they will cost some people to view (some people still pay for downloads by the megabyte.) You therefore don’t want to waste your bandwidth on large pages cluttered up with styling and layout information in every HTML file. A much better alternative is to make the HTML files stripped down and neat, and include the styling and layout information just once in a separate CSS file. To see an actual case of this in action, check out the A List Apart Slashdot rewrite article where the author took a very popular web site and re-wrote it in XHTML/CSS.
Ease of maintenance: Following on from the last point, if your styling and layout information is only specified in one place, it means you only have to make updates in one place if you want to change your site’s appearance. Would you prefer to update this information on every page of your site? I didn’t think so.
Accessibility: Web users who are visually impaired can use a piece of software known as a “screen reader” to access the information through sound rather than sight — it literally reads the page out to them, and it can do a much better job of helping people to find their way around your web page if it has a proper semantic structure, such as headings and paragraphs. In addition keyboard controls on web pages (important for those with mobility impairments that can't use a mouse) work much better if they are built using best practices. As a final example, screen readers can’t access text locked away in images, and find some uses of JavaScript confusing. Make sure that your critical content is available to everyone.
Device compatibility: Because your HTML/XHTML page is just plain markup, with no style information, it can be reformatted for different devices with vastly differing attributes (eg screen size) by simply applying an alternative style sheet — you can do this in a few different ways (look at the [mobile articles on dev.opera.com] for resources on this). CSS also natively allows you to specify different style sheets for different presentation methods/media types (eg viewing on the screen, printing out, viewing on a mobile device.)
Web crawlers/search engines: Chances are you will want your pages to be easy to find by searching on Google, or other search engines. A search engine uses a “crawler”, which is a specialized piece of software, to read through your pages. If that crawler has trouble finding the content of your pages, or mis-interprets what’s important because you haven’t defined headings as headings and so on, then your rankings in relevant search results will probably suffer.
It’s just good practice: This is a bit of a “because I said so” reason, but talk to any professional standards-aware web developer or designer, and they’ll tell you that separating content, style, and behaviour is the best way to develop a web application.
Additional stackoverflow articles:
Using <style> tags in the <body> with other HTML
Will it be a wrong idea to have <style> in <body>?
Ok so I am in the process of building my first Javascript 'framework' or 'bootstrap' which will be implemented in combination with a single pre-processed CSS file. I am gathering my favorite content slider, smooth scroller, content slideshow, parallax elements & bg-img, sticky elements, among a few more cutting edge navigational & UI based scripts (cross-browser/platform/device/viewport compatibility and performance). My problem is when constructing my demo page with all combined elements in place loaded and active on the page... well many seeem to require a different version of Jquery to be called in order to function properly. I have managed to get them to work properly while testing by carefully reordering the jquery librarys as they are called in the of the page. Now here is my (2) part question:
How do I get all my JQuery to work properly without loading multiple versions of it (one for each script almost)
I have a sample in my portfolio which I would love to use as the example. http://www.nicholasabrams.com/ (non mobile device version). In the src for that URL you will see only (1) js and (1) css - including the jquery libraries which are ALSO included in the single .js in the begining of the file. Please don't flame me, as I am asking for help. The link above works fine now (with apple as a slight exception)... but I am just trying to eliminate any bad practices I have as I have just started as a web developer at my first large company. Thanks!!
PS: Would post a snippet but its quite a large js file as you would imagine but if you will, please inspect my src and let me know what you think because my sites first load decreased from 22 seconds to 4-7 seconds after doing the above I wish I could just include the latest version of JQuery!)
if I understand you correctly you are loading more than one jQuery library to the page (in different order)? That's a mistake - you shouldn't do that.
What you should do is make sure that the plugins you work with are compatible with the library you are working with. If they're not - wither find other plugins or fix the ones you have to support the jQuery language you are using.
You have a 2 megabyte hi-res background image, that is insane! I would scrap that and the swirl image, while it may look cool to you, it is distracting and may actually make people want to avoid your website. It makes it difficult to concentrate on the text in the middle of your screen. You don't want people to remember the swirling image, but rather your portfolio, right?
You also have 404's on the following:
http://www.nicholasabrams.com/ScrollSpy_files/result-light.css
http://www.nicholasabrams.com/example-images/testing_station.png
404's are bad for several reasons, they are a wasted resource as they slow the loading of your page, because it attempts to find something and does not find it, and, finally, they have a negative impact on your SEO, specifically Google PageRank docks you for any 404's.
Find a way to work with one version of jQuery, it will eventually bite you to have multiple versions of the library and it is a bandwidth killer to have your users load up a bunch of libraries, even if they are CDN'd.
I am developing a large scale HTML5 app, and I really wonder about this issue. I will have a lot of dialog boxes and tabs that will open by user interaction.
I wonder what is the best practice - writing all the dialog boxes and tabs in the HTML document with display:none to all of them, or create these HTML sections on the fly with JS or jQuery every time the user making the relevant interaction.
What is better in terms of performance, ease of development, readability, etc?
Any help will be appreciated.
I'll try to address this question as good as I can.
1 - As I said in the comments, Avoid inline styling.
First and foremost this is because inline styling voilates DRY.
Having to repeat the same thing over and over again for this is very bad for maintenance and for developing since instead of changing code once you have to change it at ~100 places.
2 - Avoiding inline styling is also good for accessibility, some screen readers and search engine crawlers do indexing work and reading work based on css selectors and thusly using inline styling will force them to either ignore or misintrepret things.
3 - When working as developers it's easy to do inline styling "just for the fun" but what you're actually doing is mixing concerns. HTML is the content and CSS is the design.
Mixing these two usually leads to headaches and making my job as a developer that comes after you a pain in the effin ass since I have no idea what's styled and how.
Now, onto performance.
When you use inline styles, what you're telling the browser is basically "hey, for every page page view apply these styles to all of these elements." Now, this just became really apparent why this is bad.
You have no ability to cache and store your css and basically forces the browser to rerender your styles every time. Using an external CSS file will actually help you speed up your site since the browser caches it.
That was that for the css part.
The javascript you had asked about.
As I said, hide things with css and show with javascript. Now why do you want to do this instead of pulling everything in?
Well, you can do both. If you're only a webbrowser experience then you can do either, it doesn't matter. I myself prefer to have stuff in the DOM because it relates to content and if you're a large app having dozens of dozens of ajax calls will only make it harder for maintenance. I believe if you have to ajax stuff in make sure it counts and is logical and not just for the kicks (I think this applies if only you have jQuery and plain javascript at your disposal).
If you're working with backbone.js, for example, it's based on views and introduces some form of "MVC" into your frontend enabling you to have views with subviews that can pull content in from the server.
Hope that helps a bit with making a decision! :)
I would say it depends on how many tabs your application has and how big these are.
Big content inside the tabs mean that the application will take long to load when started and consume much ram. If this is the case, I suppose to load them as needed.
Small content inside the tabs will load fast, so load everything at once to increase performance when the tabs are clicked.
Don't forget to run some tests on older computers with a slow internet connection to see how your application behaves. Not everyone has the newest and fastest hardware.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a javascript snippet that clients can put on their webpages that loads some text associated with embedded flash objects (like Slideshare presentations) on that page. Does Google crawl this type of content? Will this provide any SEO benefit? If not, what else should I consider. I don't want to force people to embed the actual content since they typically have multiple pages that use this script and the there is typically a lot of text. Any suggestions?
google does execute on page javascript quite well, but the current seo consensus is that external javascript (i.e.: asynchronous loaded content )does not count as part of the page.
this means, that script (the loaded text) is not seo valuable.
if you want the text to be valuable it must be onpage, means it must be in the html of the page, so basically you will have to go with the big (text already included) js snippet.
but before you rush to make it "seo-valuable"e please be aware that duplicate content is usually not valuable. so if the text shows up on different pages it might not be useful to include the text at all.
Flash is popular on the Web, but each presents challenges to the search engines in terms of indexing the related content. This creates a gap between the user experience with a site and what the search engines can find on that site.
It used to be that search engines did not index Flash content at all. In June 2008, Google announced that it was offering improved indexing of this content
(http://googlewebmastercentral.blogspot.com/2008/06/improved-flash-indexing.html).
This announcement indicates that Google can index text content and find and follow links within Flash files. However, Google still cannot tell what is contained in images within the Flash file. Here are some reasons why Flash is still not fully SEO-friendly:
Different content is not on different URLs
This is the same problem you encounter with AJAX-based pages. You could have unique frames, movies within movies, and so on that appear to be completely unique portions of the Flash site, yet there’s often no way to link to these individual elements.
The breakdown of text is not clean
Google can index the output files in the SWF file to see words and phrases, but in Flash, a lot of your text is not inside clean or tags; it is jumbled up into half-phrases for graphical effects and will often be output in the incorrect order. Worse still are text effects that often require “breaking” words apart into individual letters to animate them.
Flash gets embedded
A lot of Flash content is only linked to by other Flash content wrapped inside shell Flash pages. This line of links, where no other internal or external URLs are referencing the interior content, means some very low PageRank/link juice documents. Even if they manage to stay in the main index, they probably won’t rank for anything.
Flash doesn’t earn external links like HTML
An all-Flash site might get a large number of links to the home page, but interior pages almost always suffer. For embeddable Flash content, it is the HTML host page earning those links when they do come.
SEO basics are often missing
Anchor text, headlines, bold/strong text, img alt attributes, and even title tags are not simple elements to properly include in Flash. Developing Flash with SEO in mind is just more difficult than doing it in HTML. In addition, it is not part of the cultural lexicon of the Flash development world.
A lot of Flash isn’t even crawlable
Google has indicated that it doesn’t execute external JavaScript calls (which many Flashbased sites use) or index the content from external files called by Flash (which, again, a lot of Flash sites rely on). These limitations could severely impact what a visitor can see versus what Googlebot can index.
Note that it used to be that you could not test the crawlability of Flash, but the Adobe Search Engine SDK does allow you to get an idea as to how the search engines will see your Flash file.
You can have the content on an external page.
If you don't want Google to crawl it, block it with robots.txt
If you don't want Google to index it (possibly a better option) use x-robots or noindex in the head.
Whether you use javascript to pull it into the page, iframes, or both really comes down to implementation and what the included page may need to access on the page, tracking, sessions etc.
Although google does not crawl flash and java script so well but these are not the only things crucial for SEO. There are many other things which matters such as keyword density, quality of content, inboubd and outbound linking, titles and content should be well managed with proper tags etc. So if flash/java script is necessity then use it but do not use it in excess.
Google is not efficient at reading or indexing flash elements. If I had to publish content like slideshare, I would produce a PDF. This can be indexed with no problem, it could drag traffic to my website.
Google crawls Flash objects to some extent. But in my experience a best solution (if Flash is imminent) is to use SWFObject for alternative HTML text. This will make your Flash and your Site 100% Google friendly and, more importantly, user friendly.
For more information go here:
http://www.adobe.com/devnet/flashplayer/articles/alternative_content.html
People read way too much into what Google will think about the technology or specific code they use on their site. If you're on the up-and-up and not using the code to cloak, deceive visitors or hijack sessions...you're going to be just fine. Will you rank better if you subbed all text for Flash? Maybe a little, but at the end of the day it's the quality of your content (yes, even if it's not text-based), the number of people that find it useful (via high quality links) and other small factors.
8 years ago, your answer would have been more valid for not including JS, but it just doesn't matter much anymore, Google treats navigable websites the same and ranks primarily around "quality", not usability excessive keyword rich text.