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 9 years ago.
I am using fancyBox to display menus/dialogues to users of an app I am building. The content displayed in the box is HTML - I could generate it all in JS and put it into a hidden div to display when needed, or make an AJAX call to fetch the content when a fancyBox is opened.
Is there any downside to having a bunch of hidden divs in a page (performance issues on mobile browsers etc)? I'd prefer to do it this way as the user experience is obviously going to be snappier.
In general, you should load information as soon as you can as the time to complete requests is the main bottleneck in most web apps. The issue here is not so much the html but the assets that are requested in addition to the html (e.g. images, videos, etc). These take up memory and also, potentially slow down the initial page load time as you could be blocking visible image loads by loading images that are not (yet) visible. To work out if either of these issues is a problem you don't really have any alternative but to test on your target devices. However, in your case you don't actually save any memory by fetching the assets later as they are still ultimately being fetched at some point and so the browser is going to have to be able to cope with everything being loaded in the end - therefore you might as well have them in the beginning. If page load times are an issue you could still defer loading the assets but only until the dom has rendered rather than waiting until the hidden div is needed. That way you don't hold up the page load but still have the assets when you need them. For example in JQuery:
$(function() {
$('#hiddenDiv').html(hiddenContent);
});
The assets (images, etc) will not be requested until the html referencing them has been added to the dom.
Related
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.
Just found out about the CSS tilde selector and it seems like it could be an elegant way to handle toggling input visibility.
The use-case I have in mind is when you only want to display an input to the user when they have checked a checkbox. Currently I do this with javascript and attach listeners to each checkbox, which then search through the DOM to find the appropriate input and toggle a class.
So the question is, why is this bad? And if it isn't, why isn't this prevalent? Why do we do this with .js rather than CSS? It seems to me they are both manipulating the presentation layer in fairly similar ways...
Bonus points for resources.
HTML is the Model, it contains the Data
CSS is the View, it contains the Styles
JS is the Controller, it contains the Interactions
This MVC structure makes for a powerful delegation of responsibility. When you want to change the state of a widget on a page, you can use JavaScript to change the available styling hooks:
jQuery used for brevity
$('#button').on('click', function () {
$('#widget').toggleClass('hidden');
});
CSS:
.hidden {
display: none;
}
Using this structure will easily allow you to change how interactions are performed. If you decide later that the widget should be animated, it's a simple change.
Using JavaScript also has the advantage of being backwards compatible. The percentage of users who have JavaScript disabled is remarkably few. While I highly recommend supporting people with JS disabled, that can often be done simply by showing all the content by default, and hiding things only for users who have JS enabled.
The use-case I have in mind is when you only want to display an input
to the user when they have checked a checkbox.
If you're planning to use the :checked selector for that, your app won't run in old browsers (IE < 9). If you're OK with this restriction, that is, only modern browsers concerned, CSS will do fine as well.
Using JS ensures that your site will run on older browsers too, provided the users have JS enabled.
You can also use a mix of both and it will ensure that your page works in modern browsers even with JS disabled as well as JS-enabled old browsers.
It is often easier to detect whether the browser has JS disabled (e.g. using a stylesheet inside <noscript>) than determining whether a browser supports certain CSS selectors.
Therefore using a JS solution allows you to easily place a disclaimer asking the user to enable JS for the page to work properly.
Though, again, if your site is not aimed at general public that may be using IE8 and below, the CSS solution will do just fine.
I would say if you can get away with using the tilde selector, or css in general, then go for it. CSS imho is a cleaner, usually more concise and superior performance way to accomplish the same thing as toggling the item in js. Plus, the browswer support for the tilde is quite good - see http://www.quirksmode.org/css/contents.html
There are times when you must use javascript to accomplish this, for example the element to hide is not a sibling or a descendant of the element in question.
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.
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.
I'm making a text based game in JavaScript, and I'm looking for a command line widget, with the following features:
print - Be able to send a synchronous command to put some text (preferably support arbitrary HTML) into the command line.
commands - Be able to specify commands which a user can type in, which will then execute functions (should support parameters to such commands, and preferably also have an auto-complete).
prompt - Be able to request input (and send that input to a callback). This should queue prints, and disable commands.
The user shouldn't be able to edit output text (but should be able to copy and paste).
Preferably using semantic elements.
Browser Support: Latest Firefox & Chrome, preferably also IE9, latest Safari & Opera.
Does anyone know about any such preexisting widget, if not, can anyone give me tips for how to make one?
It's not as tricky as you'd think to make this. I made one recently for a project, using HTML elements and jQuery JS.
I used an input element for the input line - handling special keypresses like enter and tab. For previous commands and responses I used a scrollable area which I appended new elements to as new inputs or responses were available.
I displayed the commands and responses in DIVs, which allowed for copy and pasting (and HTML formatting). I even made the responses disclosable so I'd only show the command initially and you could click on the 'expand' button to show the rest of it.
It all worked really well in the end. Just a few simple HTML elements and some jQuery code which wasn't as complex as I thought it would be when starting it. By far the most complexity and most code was in tweaking the aesthetics!
Look here that is a »virtual box« coded in Javascript with Linux running in it, the terminal might be something you could have a look at it. As far I looked at it, there is done with tables.
Greeting...
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.
I'm working on a project currently and have written the entire page in Javascript.
I created a basic function:
create_element(parent, type, style, attributes);
Example Usage:
var container = create_element(document.body, "div", {width: "100%", height: "100%"});
var header_bar = create_element(container, "div", {width: "100%", height: "50px"});
var title_span = create_element(header_bar, "span", {fontSize: "18px", fontFamily: "arial", color: "black"});
title_span.innerHTML = "Example Website";
And so on...
I use this approach for the entire layout of the website. Is there a huge disadvantage to using this method? The obvious one is that fact that there may still be people out there with JS disabled.
Is there a tangible difference in page load times if Javascript is creating and rendering the items rather than them being hard coded into the HTML?
Thanks!
TL;DR -
Created a create_element function, and use it to draw all elements onto the screen. Including the base layout for the page.
There are a number of issues that you'll run into when you try to dynamically generate non-dynamic content:
Maintainability will become very difficult. If you want to make a sweeping change to your site, you're going to have to edit JS rather than just changing CSS or some HTML.
SEO - Google can't index dynamic data. This is not good if you want your site to be found via search engines.
You are mixing your layers. By not separating concerns (your views vs. your content vs. ...), you, again, increase maintainability issues and create a problem for your future-self or another developer who has to touch your code in the future.
Now, it's not wrong to do some dynamic generation - but do it appropriately. I would highly advise against dynamically generating content for your entire site.
Update Based on Comments on Original Question
That's great you enjoy JS. And, I definitely agree that HTML can be a bit boring. But, if you are properly separating your concerns, you really should have to write very little HTML and can quickly get back to what you enjoy coding in. But, be careful that you are not trying to force fit a language into something it was not meant to do when another language was created to do it perfectly. (Hammer/Nail Rule)
Also, don't forget that HTML5 and CSS3 is extremely powerful. You can do a lot with it and never have to even touch JS (assuming that meets client needs).
One major problem is that Google will not index any content of your site if you build it like this.
Also, this way your content, your logic and your styling will not be separated, which i think is a huge benefit if you use html / css in seperate files and a server side scripting language.
It is not wrong for an entire website to be generated by javascript based on the response from server if you ensure that metadata used for rendering the page is not evaluated as a whole as this leads to security issues.
In my opinion, it would be really better to use html as it is, if it's not dynamic content.
furthermore, having separate CSS files is more appropriate than setting it inline.
BackboneJS does this. You just have to ensure that JS is used client-side to complliment server side rendering, and that any rendering done solely on the client is capable of being in whole or part on the server as well.
There's no reason that a pages contents couldn't entirely be generated by javascript, but I wouldn't endorse this element by element approach. You aren't even using any style rules, only inline styles. Furthermore, in this case it'd be more maintainable to use some sort of templating mechanism for blocks of html, such as used in Underscore.js. (There are many templating solutions out there, like Mustache and Handlebars; I'm just giving one I've used.) There are several ways to maintain the html without it being in some javascript file somewhere, but even if it were in a javascript file, it'd be more maintainable than this element by element business.
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.
We are in need of a DOM parser, that will be able to run a bunch of patterns and would store the results. For this we are looking for libraries that are open and we can start on,
able to select elements by regexp (for example grab all elements that contain "price" either in class, id, other attributes like meta attributes),
should have a lot of helpers like: remove comments, iframes, etc
and be pretty fast.
can be run from browser extensions.
Ok, I'll say it :
You can use jQuery.
ups :
it is a very good dom parser
it is very good at manipulating the dom (removing/adding/editing elements)
it has a great and intuitive api
it has a big & great community => lots of answers to any jquery related question
it works in browser extensions (tested it myself in chrome and it apparently works in ff extensions too : How to use jQuery in Firefox Extension)
it is lightweight (About 31KB in size - minified and gzipped)
it is cross-browser
it is definitely open source
downs :
it doesn't rely on regex (although this is a very good thing - as dda already mentioned), but regex can be used to filter the elements
dont know if it can access/manipulate comments
Here's an example of some jquery action :
// select all the iframe elements with the class advertisement
// that have the word "porn" in their src attribute
$('iframe.advertisement[src*=porn]')
// filter the ones that contains the word "poney" in their title
// with the help of a regex
.filter(function(){
return /poney/gi.test((this.title || this.document.title).test()));
})
// and remove them
.remove()
// return to the whole match
.end()
// filter them again, this time
// affect only the big ones
.filter(function(){
return $(this).width() > 100 && $(this).height() > 100;
})
// replace them with some html markup
.replaceWith('<img src="harmless_bunnies_and_kitties.jpg" />');
node-htmlparser can parse HTML, provides a DOM with a number of utils (also supports filtering by functions) and can be run in any context (even in WebWorkers).
I forked it a while back, improved it for better speed and got some insane results (read: even faster than native libexpat bindings).
Nevertheless, I would advice you to use the original version, as it supports browsers out-of-the-box (my fork can be run in browsers using browserify, which adds some overhead).