I've created a pretty basic system here at work that does what Google analytics does (extremely simplistic in comparison) and it works quite well, but like Google Analytics it requires each page to reference a JavaScript file. Is there any way to make all of our pages that are served from IIS reference this Javascript file? I would like to capture these stats for every page.
Any ideas?
Thanks
Hmm, it looks like you are looking for this.
If you're dealing with static HTML files your best bet seems to be this previous question.
If you have an ASP site going, and you already have a header or layout file, I'd recommend putting it in there.
This depends on how you build your web site, but most people do this by adding the reference to their templates, layouts, master pages, or whatever term is used in your development platform.
You don't want every page tracked, e.g., pages returning data such as JSON or XML should not be meddled with. This is why it is better to have explicit control over which pages get the analytics javascript added to them.
Related
We have a web app that its content generated by javascript. Can google index those pages?
When we investigate this issue we always found solutions from old pages about using "#!" in links.
In our app the links are like this:
domain.com/paris
domain.com/london
When we use these kind of links, javascript populates content.
Is it wise to use HTML snapshot or do you have any other suggestions?
Short answer
Yes they can crawl JavaScript generated content, as long as you are using pushstates.
Detailed answer
It depends on your setup. Google and Bing CAN crawl javascript and AJAX based content if your are using pushstates. If you do they will handle content coming from AJAX calls, updates to page title or meta tags using javascript, and in general any such things.
Most frontend frameworks like Angular, Ember or Backbone already works with pushstates so in these cases you don't need to do anything. Check whatever system you are using to see how they do things. If you are not using pushstates you will need to implement it on your own or use the whole escapted_fragment html snapshot deal.
So if you use pushstate then yes, search engines can crawl your page just fine. If you don't then no, you will need to implement pushstates or do HTML snapshots.
Bonus info - Unfortunately Facebook does not handle pushstates, so the facebook crawler needs either non-dynamic og-tags or HTML snapshots.
"Generated by JavaScript" is ambiguous. That could mean that you are running a JS script on the server or it could mean that you are making an AJAX call with a JS API. The difference appears to matter as far as Googlebot is concerned. But you don't have to take my word for it, as there is empirical proof of what Googlebot will and won't currently cache as far as JavaScript content in the form of live experiments using both the XMLHTTPRequest API and the Fetch API. So, as you can see, server-side rendering is still going to be the best way to go for SEO.
This is a follow-up to my previous question.
Suppose there is a single web page with a login form and sign-up link. When a user clicks on the link a new sign-up form is displayed. Suppose also I create separate HTML, CSS, and JavaScript files for both forms for modularity.
Now the web page should contain some JavaScript code to load the login form, when the page is loaded, and load the sign-up form upon click on the link.
Does this approach make sense? Are there any frameworks/libraries, which implement this approach? How would you suggest implement it?
I think the idea has some issues. First you should know that there are some old fashion ways to load another completely separated page in the main document. Using "iframe" tag is one of the most popular and unsecure ways to do such a thing. Showing popups and use "window.open" is another way that can show a new window and load the specific url completely separated. BUT...
There are many reasons that I'm now gonna suggest you not to do that in any of mentioned ways. You can simply use some libraries like "JQuery" to load another html in the current page without any need to load new resources that cause performance issues for you. I believe you should search for "JQuery $.get" and you will see how easy it would be.
Hope it helps.
Cheers
Yes that makes sense to me. I really like this approach as I think breaking an app into smaller chunks will make the development & maintenance much easier.
Basicly you need to load the css and js files by appending a link and script tag respecticly into the head section of the html. For loading the html part of the module you can simply use jQuery.get() method as suggested by other answer.
I have tried to implement it. I recently released my work on this. a small code base. actually in my approach each module has its own folder with its js, html and css files and optionally a server-side file too like a php or aspx file that will be called by javascript to query the server.
here is the project page in github called Yuva
take a look and let me know if this makes sense to you.
Here's my problem: I want to build a website, mostly static but with some dynamic parts (a little blog for news, etc..).
My webserver can only do static files (it's actually a public dropbox directory!) but I don't want to repeat the layout in every html page!
Now, I see two possible solutions here: either I create an index.htm page that emulates site navigation with javascript and AJAX or I create all the different html pages and then somehow import the layout bits with javascript..
From you I need ideas and suggestions on how to implement this, which libraries to use, or maybe there exists even something tailored exactly for what I need?
Thanks!!
I would define the site layout in your index.html file, and then use JavaScript and Ajax to load the actual content into a content div on the page. That way your content files (fetched by Ajax) will be more or less plain HTML, with CSS classes defined in index.html. Also, I wouldn't recommend building a blog in pure HTML and JavaScript. It wouldn't be very interactive; no comments, ratings, etc. You could store your blog content in XML and then fetch and display it with Ajax and JavaScript, however.
While on the subject of XML, you could implement all your site content in XML. You should also store the list of pages (for generating navigation) as XML.
Just another one way. You can generate static HTML in your computer and upload result to dropbox. Look at emacs muse.
jQuery allows you to easily load a section of one page into another page. I recommend loading common navigation sections into the different pages, rather than the other way around to avoid back/forward problems. Layout can be done with a separate CSS file rather than with tables to minimize the amount of repeated code. For the blog, you could put each blog entry in a separate file and load each section individually.
However, I would just use something already available. TiddlyWiki, for example, is a self-contained wiki that is all in one file. It's very customizable, and there's already a blog plug-in available for it. You can work on the site on your hard drive or USB drive, and then you can upload it to the web when done. There's nothing more to it.
Have you considered using publishing software on your computer to combine your content with a template, resulting in a set of static pages that you can then upload to the dropbox?
Some options in this regard come to mind:
Movable Type - can output static HTML which can then be uploaded to the server
Adobe Dreamweaver
Apple iWork Pages
To handle comments, you can use Disqus. It inserts a complete comment system into your site using just JavaScript.
You can use the Google Closure templates. It's one of the fastest and most versatile javascript templating solutions around.
Is there a way to have a blog directly integrated into my HTML/javascript-only website, without having to have something like a SQL-database and a dynamic engine like PHP or MySQL?
Maybe there is some service in the web that offers this (hopefully without ads :) ). Or maybe I can have a blog engine entirely written in javasript?
Entirely written in JavaScript? Surely that defeats the entire point of having a "blog-engine" in the first place? The point being that the data is stored somewhere and dynamically retrieved. To avoid using anything server-side (which seems to be your intent), and only use HTML/JavaScript, you'd have to store all the data for the blog in files that are served up to each visitor, and then retrieve the data from the particular, local, locations using JavaScript.
Sorry if I'm misunderstanding the point here... but this seems to be an utterly useless way of trying to go about things. Blogs are, in general, either written statically (in HTML [even though this is rare]), or are dynamically generated from a database by a server-side scripting language (most common).
Edit: As an additional point, I suppose you could include some third-party blog feed, or service, in your page, via use of JavaScript... but I'm unsure as to which (if any) blogging services would directly support this method of working. Additionally, this is quite an unreliable way of including third-party data in a page...
Here's a thought. It's not really a blog engine - but a wiki.
Entirely javascript/html/css. All lives in a single html file:
http://www.tiddlywiki.com/
not sure how it would work on a real live site, but their site is using it:
* A personal notebook
* A GTD ("Getting Things Done") productivity tool
* A collaboration tool
* For building websites (this site is a TiddlyWiki file!)
* For rapid prototyping
* ...and much more!
You could use github pages. You will get a generated blog with version control.
Other option is to use a Desktop blog tool and then update your site.
You can user iWeb if you have a Mac or CityDesk on Windows or you may try this open source tool
Edit Today I came across this tool: Zeta producer that may help.
http://code.google.com/p/showdown-blog/
Blog engine written in just JS and XML [v0.6] {JavaScript, XML}
So, what you want is to have a blog where you're website provider doesn't provide a way to serve dynamic content?
The only way I see that you can do it in that case is writing html-files (or text-files if you prefer) and adding them to the site. After that you can have some JavaScript to add them to your "blog-page".
You of course need to upload them to the website in the same way as you do for the other files, and then have a way for the JavaScript to know which pages it should fetch.
I am not aware of any JavaScript blog-engines, but you can have a look at the templating functions in for instance Prototype
Of course, that means that you will have to fetch both the template and the content through Ajax and let the client do all the processing (could be slow and possibly insecure), and you still need to have a place to upload the content and update it.
Your best bet is going to be using a generator to create the HTML/CSS/JS to upload to your server, take a look at Webby: http://webby.rubyforge.org/
IF you really need to you can use a public api for a service that lets you post small bits of info and retrieve it using javascript.
for example if you only need small posts you can make a blog in html.javascript that utilizes twitter as the engine. of course you will be limited to 140 chars. I am sure there are other services that will allow a similar idea but with less restrictions.
And of course the best option - Get a blog software or host your blog with a service provider and link to it from you site.
Good luck
One solution would be to use some application that generates the static web pages of your blog, and uploads them to your web server. This way you'd have a blog with static content that could all be managed in javascript alongside your existing site, without needing to install database, daemon software, or additional dynamic web programming languages on your server. The static content generation could happen directly on your server if possible, or you could run the html generation tool locally and upload the output.
MoveableType has a tool like this. You still need somewhere to store the content of your blog, and for this MoveableType uses MySQL by default, so you'd still need to install a database somewhere, but the database could simply be one your local desktop.
MoveableType also has support via plugins or older versions that can retrieve data from a sqlite or other database. The advantage of sqlite is that it doesn't require installing daemons like MySQL does, you can just put a sqlite file on disk somewhere, give MoveableType the path to the file, and run the script to generate your static content.
There are likely other tools like MoveableType, and I have in the past generated blog-like web pages simply by writing small scripts to generate HTML. The main issue is just that you need somewhere for these scripts to fetch data from.
Another option might be to develop your blog using XSLT, ... with XSLT, you'd put the content of your pages in XML files, and then write a template in XSL that converts your XML to HTML.
If you google for 'static blog site generation' you might find other ideas/options, including Jekyll/github mentioned in one of the other responses.
Do you localize your javascript to the page, or have a master "application.js" or similar?
If it's the latter, what is the best practice to make sure your .js isn't executing on the wrong pages?
EDIT: by javascript I mean custom javascript you write as a developer, not js libraries. I can't imagine anyone would copy/paste the jQuery source into their page but you never know.
Putting all your js in one file can help performance (only one request versus several). And if you're using a content distribution network like Akamai it improves your cache hit ratio. Also, always throw inline js at the very bottom of the page (just above the body tag) because that is executed synchronously and can delay your page from rendering.
And yes, if one of the js files you are using is also hosted at google, make sure to use that one.
Here's my "guidelines". Note that none of these are formal, they just seem like the right thing to do.
All shared JS code lives in the SITE/javascripts directory, but it's loaded in 'tiers'
For site-wide stuff (like jquery, or my site wide application.js), the site wide layout (this would be a master page in ASP.net) includes the file. The script tags go at the top of the page.
There's also 'region-wide' stuff (eg: js code which is only needed in the admin section of the site). These regions either have a common layout (which can then include the script tags) or will render a common partial, and that partial can include the script tags)
For less-shared stuff (say my library that's only needed in a few places) then I put a script tag in those HTML pages individually. The script tags go at the top of the page.
For stuff that's only relevant to the single page, I just write inline javascript. I try to keep it as close to it's "target" as possible. For example, if I have some onclick js for a button, the script tag will go below the button.
For inline JS that doesn't have a target (eg: onload events) it goes at the bottom of the page.
So, how does something get into a localised library, or a site-wide library?.
The first time you need it, write it inline
The next time you need it, pull the inline code up to a localised library
If you're referencing some code in a localized library from (approximately) 3 or more places, pull the code up to a region-wide library
If it's needed from more than one region, pull it up to a site-wide library.
A common complaint about a system such as this, is that you wind up with 10 or 20 small JS files, where 2 or 3 large JS files will perform better from a networking point of view.
However, both rails and ASP.NET have features which handle combining and caching multiple JS files into one or more 'super' js files for production situations.
I'd recommend using features like this rather than compromising the quality/readability of the actual source code.
Yahoo!'s Exceptional Performance Team has some great performance suggestions for JavaScript. Steve Souders used to be on that team (he's now at Google) and he's written some interesting tools that can help you decide where to put JavaScript.
I try to avoid putting javascript functions on the rendered page. In general, I have an application.js (or root.js) that has generic functionality like menu manipulation. If a given page has specific javascript functionality, I'll create a .js file to handle that code and mimic the dir structure on how to get to that file (also using the same name as the rendered file).
In other words, if the rendered page is in public/dir1/dir2/mypage.html, the js file would be in public/js/dir1/dir2/mypage.js. I've found this style works well for me, especially when doing templating on a site. I build the template engine to "autoload" my resources (css and js) by taking the request path and doing some checking for the css and js equivalents in the css and js directories on the root.
Personally, I try to include several Javascript files, sorted by module (like YUI does). But once in a while, when I'm writing essentially a one-liner, I'll put it on the page.
Best practice is probably to put it on Google's servers.
(Depends what you mean by "your" javascript though I suppose :)
This is something I've been wrestling with, too. I've ended up by using my back-end PHP script to intelligently build a list of required JS files based on the content requested by the user.
By organizing my JS files into a repository that contains multiple files organized by purpose (be they general use, focused for a single page, single section, etc) I can use the chain of events that builds the page on the back-end to selectively choose which JS files get included based on need (see example below).
This is after implementing my web app without giving this aspect of the code enough thought. Now, I should also add that the javascript I use enhances but does not form the foundation of my site. If you're using something like SproutCore or Ext I imagine the solution would be somewhat different.
Here's an example for a PHP-driven website:
If your site is divided into sections and one of those sections is calendar. The user navigates to "index.phhp?module=calendar&action=view". If the PHP code is class-based the routing algorithm instantiates the CalendarModule class which is based on 'Module' and has a virtual method 'getJavascript'. This will return those javascript classes that are required to perform the action 'view' on the 'calendar' module. It can also take into account any other special requirements and return js files for those as well. The rendering code can verify that there are no duplicates of js files when the javascript include list is built for the final page. So the getJavascript method returns an array like this
return array('prototype.js','mycalendar.js');
Note that this, or some form of this, is not a new idea. But it took me some time to think it important enough to go to the trouble.
If it's only a few hundred bytes or less, and doesn't need to be used anywhere else, I would probably inline it. The network overhead for another http request will likely outweigh any performance gains that you get by pulling it out of the page.
If it needs to be used in a few places, I would put the function(s) into a common external file, and call it from an inline script as needed.
If you are targeting an iphone, try to keep anything that you want cached under 25k.
No hard and fast rules really, every approach has pros and cons, would strongly recommend you check out the articles that can be found on yahoo's developer section, so you can make informed decisions on a case by case basis.