I am building a web application with Angular JS, I need this to be fully SEO-optimized.
It seems that for a few, google is able to crawl angular app but it is not clear if it can read everything (eg I read that directives cannot be interpreted).
So today, is an angular app fully google-compatible even if we use the full set of JS functions? What about other engines? Do we still need fantomJS static generation for Yahoo or microsoft?
As of today, AngularJS is still not fully SEO-optimized. Thus, a lot of developers still find it necessary to use services like Predender.io or cooking up their own implementation by using PhantomJS
Great strides have been made towards SEO-friendliness, especially when talking about AngularJS 2.0 since it allows you to render HTML on the server side (More info here).
However, even with the new additions it's better to retain control over what the search engines are seeing by creating pre-rendered versions of your site.
Here is a great article about this very topic: https://builtvisible.com/javascript-framework-seo/
To quote some parts of it:
Google can render and crawl JS sites. This, however is no guarantee that the outcome will be an SEO friendly, perfectly optimised site! Technical SEO expertise is needed, especially during testing. This will ensure that you have an SEO friendly site architecture, targeting the right keywords. A site that continues to rank despite the changes made in Google’s crawl.
In my opinion, it’s better to retain tighter control of what’s being rendered by serving Google a pre-rendered, flat version of your site. This way, all the classic rules of SEO apply and it should be easier to detect and diagnose potential SEO issues during testing.
As far as other search engines, it seems like they currently don't support javascript rendering yet: https://www.bing.com/webmaster/help/webmaster-guidelines-30fba23a
The technology used on your website can sometimes prevent Bingbot from being able to find your content. Rich media (Flash, JavaScript, etc.) can lead to Bing not being able to crawl through navigation, or not see content embedded in a webpage. To avoid any issue, you should consider implementing a down-level experience which includes the same content elements and links as your rich version does. This will allow anyone (Bingbot) without rich media enabled to see and interact with your website.
I have an existing intranet webapp (solely internal) built with ExtJS using an "iframe architecture", i.e. it has a top menu and a tabpanel on an index page and about 30 other separate webpages that open as iframes "tabs" inside the main tabpanel.
There is not any particular reason to use iframes, everything is on the same domain and most of these other seperate pages are written using the ExtJS library almost solely in javascript. The html on almost all of them consists of empty HTML, HEAD and BODY tags.
I would really like to refactor this using the ExtJS MVC architecture and ditch the iframes but because "everything works" I can't justify taking the time to do this.
One thought I had but haven't been able to test is: with every one of these separate pages having it's own Ext.onReady event and viewport, etc, this webapp must be loading the full ExtJS framework for every iframe-tab it opens, seriously magnifying client resource usage. Can anyone confirm that this type of architecture would do that with the ExtJS framework?
Is there any other very solid reasons this should be refactored?
Or, would refactoring to MVC architecture only give me easier code maintenance and no performance boosts? (being that currently everything works as intended)
Unfortunately I don't have project similar to what you have handy so I can't test it myself but here are my 2c... :)
I do think each page will initiate its own copy of ExtJs framework but I think it only has an affect on CPU and memory usage. Network traffic should not be very different as core ExtJs files will be cached.
I do recommend to check out network traffic while running this app as you will see how exactly browser handles all this. You might want to add some additional logic into core ExtJs functions to confirm if framework is in fact instantiated several times.
If end users experience some performance issues - it might be very good point to justify re-factoring. Otherwise it's kind of hard. Unless of course you have some plans of expanding functionality in near future and planning on continue working on this application.
One of the design proposed for a web application I am working on suggests using javascript to generate all html content. Basically to create a page in the application you would use a homemade javascript framework to build the dynamic html on the page. The pages of this webpage are very complex and all of the html markup would be generated via javascript using our custom built framework. The framework would essentially need a method to create each element on the page you wanted to produce.
What are some of the pros and cons of this approach?
The biggest cons of it are that you must rely on the end user's client browser to correctly render all of your content. An out of date browser or an untested browser is likely to result in broken content or no content. This is distinct from and more severe than the problems those same browsers encounter with HTML & CSS they cannot correctly render. If the markup is supplied to the browser, it may incorrectly render the CSS, but at least the content will be accessible. Using a script to generate all the markup can easily result in no markup being generated.
Then there are the users who run without JavaScript, or with something like NoScript blocking most scripts. They'll not see any of your content either. Thirdly, your content will not be indexed by most search engines.
Addendum
Relating to developer skill sets, working strictly from a JavaScript framework could tromp on the web development division of labor somewhat, if you have such a division. Unless the framework is able to maintain a good separation between the generation of markup, CSS, & application script, your programmers may find themselves more deeply in the role of designer and content editor than they are accustomed to (if you have a division of labor between those aspects of development).
From the comments below, we learn that this is intended for an intranet application in a controlled browser environment. This moots the end-user testing issues mentioned above to some degree, but there is always a danger of a browser upgrade breaking application code in JavaScript.
I cannot think of any positive outcomes that would outweight the potential negative outcomes (by my own judgement, anyway)
The strategy adopted by serious web sites is to start with basic HTML, then add CSS to tidy the layout, then add script to make the users' life easier by enhancing functionality (and not to add time wasting and annoying animations). That way you always have a fallback if something doesn't work or scripting fails for some reason. I deliberately left out the "add annoying advertisements" since they aren't part of the functional design.
To design the site, you should start by determining what it is that your web site is supposed to do (i.e. the vision). Then set out some goals that achieve that vision. Then chose the most efficient design to deliver on the goals—at this point you should not have yet decided on the implementation technology.
Then choose the most appropriate technology and design based on reliability, maintainability, longevity and supportability. That will lead you to a detailed design and implementation.
If, after all that, the best option is a 100% scripted client, so be it. But the fact that very, very few web sites have chosen that architecture makes me very much doubt that it'll be the winner.
I am currently evaluating how to create and maintain MVC3 web applications that have a level of client side richness we've never attempted before. I realize this will require a much more thought out usage of javascript.
This lead to me starting research on Dojo and Closure. Of course the amount of information (especially in context with various versions) is just overwhelming on this.
Does anyone have any good sources of guidance on working with tools such as these in the context of MVC2+ style applications? Such as which mesh well, and which have the highest barriers, personal success or failure stories and so on.
This is interesting, because I think Microsoft is leaning heavily toward wanting MVC users to use jQuery in their projects. jQuery is the only JavaScript framework included by default in the MVC project at creation. They are also actively developing plugins to use in MVC projects. Now I am not saying you should use jQuery for these reasons, but it is hard to ignore how much effort MS is putting towards jQuery and making it a large part of the MVC workflow.
jQuery all the way is the only way. MVC 3 libraries use it behind the scenes anyways now. Whats the issue with simply including the scripts as opposed to relying on the dogo.requires() ?
With jQuery - simple includes on your layout pages are all you need most of the time. There is some faultiness when you want validation to occur on an ajax loaded partial view in which you need to 'tell' jQuery about the new content to validate, but besides that its quite solid.
Just stumbled onto this question: not sure whether you're still interested in it.
There are several internal initiatives inside Dojo to build an MVC module and low-level "binding" functionalities into Dojo, and use automatic binding as the "glue" between the model object and the view (or widgets inside the view).
dojox.mvc is where most of this work is currently residing.
I have a small implementation of automatic binding (similar to WPF so you can actually do MVVM with Dojo) intended as a plumbing layer in Dojo. There is a small proof-of-concept test page here: http://www.mingleplace.com/test/bindingtest.html
So, the short answer is that MVC is actively being developed/pursued in Dojo, and experimental packages are already available. However, as far as when the actual API will be formalized into Dojo, you probably have to wait till 2.0...
When a developing a web app, versus a web site, what reasons are there to use multiple HTML pages, rather than using one html page and doing everything through Javascript?
I would expect that it depends on the application -- maybe -- but would appreciate any thoughts on the subject.
Thanks in advance.
EDIT:
Based on the responses here, and some of my own research, if you wanted to do a single-page, fully JS-Powered site, some useful tools would seem to include:
JQuery Plug Ins:
JQuery History:
http://balupton.com/projects/jquery-history
JQuery Address:
http://plugins.jquery.com/project/jquery-address
JQuery Pagination:
http://plugins.jquery.com/project/pagination
Frameworks:
Sproutcore
http://www.sproutcore.com/
Cappucino
http://cappuccino.org/
Possibly, JMVC:
http://www.javascriptmvc.com/
page based applications provide:
ability to work on any browser or device
simpler programming model
they also provide the following (although these are solvable by many js frameworks):
bookmarkability
browser history
refresh or F5 to repeat action
indexability (in case the application is public and open)
One of the bigger reasons is going to be how searchable your website is.
Doing everything in javascript is going to make it complicated for search engines to crawl all content of your website, and thus not fully indexing it. There are ways around this (with Google's recent AJAX SEO guidelines) but I'm not sure if all search engines support this yet. On top of that, it's a little bit more complex then just making separate pages.
The bigger issue, whether you decide to build multiple HTML pages, or you decide to use some sort of framework or CMS to generate them for you, is that the different sections of your website have URL's that are unique to them. E.g., an about section would have a URL like mywebsite.com/about, and that URL is used on the actual "about" link within the website.
One of the biggest downfalls of single-page, Ajax-ified websites is complexity. What might otherwise be spread across several pages suddenly finds its way into one huge, master page. Also, it can be difficult to coordinate the state of the page (for example, tracking if you are in Edit mode, or Preview mode, etc.) and adjusting the interface to match.
Also, one master page that is heavy on JS can be a performance drag if it has to load multiple, big JS files.
At the OP's request, I'm going to discuss my experience with JS-only sites. I've written four relevant sites: two JS-heavy (Slide and SpeedDate) and two JS-only (Yazooli and GameCrush). Keep in mind that I'm a JS-only-site bigot, so you're basically reading John Hinkley on the subject of Jody Foster.
The idea really works. It produces gracefully, responsive sites at very low operational costs. My estimate is that the cost for bandwidth, CPU, and such goes to 10% of the cost of running a similar page-based site.
You need fewer but better (or at least, better-trained) programmers. JavaScript is an powerful and elegant language, but it has huge problems that a more rigid and unimaginative language like Java doesn't have. If you have a whole bunch of basically mediocre guys working for you, consider JSP or Ruby instead of JS-only. If you are required to use PHP, just shoot yourself.
You have to keep basic session state in the anchor tag. Users simply expect that the URL represents the state of the site: reload, bookmark, back, forward. jQuery's Address plug-in will do a lot of the work for you.
If SEO is an issue for you, investigate Google Ajax Crawling. Basically, you make a very simple parallel site, just for search engines.
When would I not use JS-only? If I were producing a site that was almost entirely content, where the user did nothing but navigate from one place to another, never interacting with the site in a complicated manner. So, Wikipedia and ... well, that's about it. A big reference site, with a lot of data for the user to read.
modularization.
multiple files allows you to mre cleanly break out different workflow paths and process parts.
chances are your Business Rules are something that do not usually directly impact your layout rules and multiple files would better help in editing on what needs to be edited without the risk of breaking something unrelated.
I actually just developed my first application using only one page.
..it got messy
My idea was to create an application that mimicked the desktop environment as much as possible. In particular I wanted a detailed view of some app data to be in a popup window that would maintain it's state regardless of the section of the application they were in.
Thus my frankenstein was born.
What ended up happening due to budget/time constraints was the code got out of hand. The various sections of my JavaScript source got muddled together. Maintaining the proper state of various views I had proved to be... difficult.
With proper planning and technique I think the 'one-page' approach is a very easy way to open up some very interesting possibilities (ex: widgets that maintain state across application sections). But it also opens up many... many potential problem areas. including...
Flooding the global namespace (if you don't already have your own... make one)
Code organization can easily get... out of hand
Context - It's very easy to
I'm sure there are more...
In short, I would urge you to stay away from relying on JavaScript dependency for the compatibility issue's alone. What I've come to realize is there is simply no need rely on JavaScript to everything.
I'm actually in the process of removing JavaScript dependencies in loo of Progressive Enhancement. It just makes more sense. You can achieve the same or similar effects with properly coded JavaScript.
The idea is too...
Develop out well-formatted, fully functional application w/o any JavaScript
Style it
Wrap the whole thing with JavaScript
Using Progressive Enhancement one can develop an application that delivers the best possible experience for the user that is possible.
For some additional arguments, check out The Single Page Interface Manifesto and some (mostly) negative reaction to it on Hacker News (link at the bottom of the SPI page):
The Single Page Interface Manifesto: http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php
stofac, first of all, thanks for the link to the Single Page Interface (SPI) Manifesto (I'm the author of this boring text)
Said this, SPI != doing everything through Javascript
Take a look to this example (server-centric):
http://www.innowhere.com/insites/
The same in GAE:
http://itsnatsites.appspot.com/
More info about the GAE approach:
http://www.theserverside.com/news/thread.tss?thread_id=60270
In my opinion coding a complex SPI application/web site fully on JavaScript is very very complex and problematic, the best approach in my opinion is "hybrid programming" for SPI, a mix of server-centric for big state management and client-centric (a.k.a JavaScript by hand) for special effects.
Doing everything on a single page using ajax everywhere would break the browser's history/back button functionality and be annoying to the user.
I utterly despise JS-only sites where it is not needed. That extra condition makes all the difference. By way of example consider the oft quoted Google Docs, in this case it not only helps improve experiences it is essential. But some parts of Google Help have been JS-only and yet it adds nothing to the experience, it is only showing static content.
Here are reasons for my upset:
Like many, I am a user of NoScript and love it. Pages load faster, I feel safer and the more distracting adverts are avoided. The last point may seem like a bad thing for webmasters but I don't want anyone to get rewarded for pushing annoying flashy things in my face, if tactless advertisers go out of business I consider it natural selection.
Obviously this means some visitors to your site are either going to be turned away or feel hassled by the need to provide a temporary exclusion. This reduces your audience.
You are duplicating effort. The browser already has a perfectly good history function and you shouldn't need to reinvent the wheel by redrawing the previous page when a back button is clicked. To make matters worse going back a page shouldn't require re-rendering. I guess I am a student of If-it-ain't-broke-don't-fix-it School (from Don't-Repeat-Yourself U.).
There are no HTTP headers when traversing "pages" in JS. This means no cache controls, no expiries, content cannot be adjusted for requested language nor location, no meaningful "page not found" nor "unavailable" responses. You could write error handling routines within your uber-page that respond to failed AJAX fetches but that is more complexity and reinvention, it is redundant.
No caching is a big deal for me, without it proxies cannot work efficiently and caching has the greatest of all load reducing effects. Again, you could mimic some caching in your JS app but that is yet more complexity and redundancy, higher memory usage and poorer user experience overall.
Initial load times are greater. By loading so much Javascript on the first visit you are causing a longer delay.
More JavaScript complexity means more debugging in various browsers. Server-side processing means debugging only once.
Unfuddle (a bug-tracker) left a bad taste. One of my most unpleasant web experiences was being forced to use this service by an employer. On the surface it seems well suited; the JS-heavy section is private so doesn't need to worry about search engines, only repeat visitors will be using it so have time to turn off protections and shouldn't mind the initial JS library load.
But it's use of JS is pointless, most content is static. "Pages" were still being fetched (via AJAX) so the delay is the same. With the benefit of AJAX it should be polling in the background to check for changes but I wouldn't get notified when the visible page had been modified. Sections had different styles so there was an awkward re-rendering when traversing those, loading external stylesheets by Javascript is Bad Practice™. Ease of use was sacrificed for whizz-bang "look at our Web 2.0" features. Such a business-orientated application should concentrate on speed of retrieval, but it ended up slower.
Eventually I had to refuse to use it as it was disrupting the team's work flow. This is not good for client-vendor relationships.
Dynamic pages are harder to save for offline use. Some mobile users like to download in advance and turn off their connection to save power and data usage.
Dynamic pages are harder for screen readers to parse. While the number of blind users are probably less than those with NoScript or a mobile connection it is inexcusable to ignore accessibility - and in some countries even illegal, see the "Disability Discrimination Act" (1999) and "Equality Act" (2010).
As mentioned in other answers the "Progressive Enhancement", née "Unobtrusive Javascript", is the better approach. When I am required to make a JS-only site (remember, I don't object to it on principle and there are times when it is valid) I look forward to implementing the aforementioned AJAX crawling and hope it becomes more standardised in future.