The previous programmer left the website in pretty unusable state, and I am having difficulty modifying anything. I am new to web design so I don't know whether my skills are a mismatch to this kind of job or is it normal in the real industry to have websites like these
The Home page includes three frames
Each of these frames have their own javascript functions ( between <head>, and also call other common javascript functions (using <script src=..>
Excessive usage of document.all - in fact the elements are referred or accessed by document.all only.
Excessive usage of XSLT and Web Services - Though I know that using Web Services is generally considered a good design choice - is there any other way I can consume these services other than using xslt. For example, the menu is created using the data returned by a web method.
Every <div>, <td> and every other element has an id, and these id's are manipulated by the javascript functions, and then some appropriate web service and the xslt files are loaded based on these..
From the security perspective, he used T-SQL's for xml auto for most of the data that is returned by the web service - is it a good choice from the security standpoint to expose the table names and column names to the end user??
I am a lot confused about the state of the application itself. Should I learn about the intricacies that he has developed and continue working on it, or should I start rewriting everything? What I am perplexed a lot is the lack of alternatives - and whether this is the common way web projects are handled in the real world or was it an exception?
Any suggestions, any pointers are welcome. Thanks
No, it is not acceptable in this industry that people keep writing un-maintainable code.
My advice to you is to go up the chain and convince everyone that this needs to be rewritten. If they question you, find an external consultant with relevant web development skills to review the application (for 1 day).
Keeping this website as-is, because it 'works' is like keeping a working model Ford-T car on today's highways, very dangerous. Security and maintenance costs are likely the most persuading topics to convince anyone against keeping this site 'as-is'.
Next, get yourself trained, it will pay off if you can rewrite this application knowing the basics. Todays technology (asp.net MVC) allows you to implement core business value faster than trying to maintain this unconventionally written app.
Tough spot for an inexperienced developer (or any) to be left in. I think you have a few hard weeks a head of you where you really need to read up on the technologies involved to get a better understanding of them and what is best practice. You will also need to really dig down into the existing code to understand how it all hangs together.
When you done all that you really need to think about your options. Usually re-writing something from scratch (especially if it actually works) is a bad idea. This obviously depend on the size of the project, for a smaller projects with only a couple of thousand lines of code it might be OK. When looking at someone elses code it is also easy to overlook that all that weird shit going on could actually be fixes for valid requirements. Things often start out looking neat, but then the real words comes visiting.
You will need to present the business with time estimates for re-writing to see if that is an option at all, but I'm guessing you will need to accept the way things are and do your best with what you have. Maybe you could gradually improves things.
I would recommend moving the project to MVC3 and rewriting the XSLT portions to function using views and/or partial views with MVC. The Razor model binding syntax is very clean and should be able to quickly cleave out the dirty XSLT code and be left with just the model properties you would need.
I would then have those web services invoked from MVC serverside and for you to deserialize the object results into real objects (or even just use straight XQuery or Json traversing to directly pull stuff out for your model) and bind those to your views.
This could be a rather gargantuan leap for technology at your company though. Some places have aversion to change.
I'd guess this was written 6-7 years ago, and hacked on since then. Every project accumulates a certain amount of bubble gum and duct tape. Sounds like this one's got it bad. I suggest breaking this up into bite size chunks. I assume that the site is actually working right now? So you don't want to break anything, the "business" often thinks "it was working just fine when the last guy was here."
Get a feel for your biggest pain points for maintaining the project, and what you'll get the biggest wins from fixing. a rewrite is great, if you have the time and support. But if it's a complex site, there's a lot to be said for a mature application. Mature in the sense that it fulfills the business needs, not that it's good code.
Also, working on small parts will get you better acquainted with the project and the business needs, so when you start the rewrite you'll have a better perspective.
Related
For the past six months or so I've been teaching myself Javascript by building a single page application that uses Raphael to create all of the elements the user sees and interacts with (see the landing page for the project for a small-scale example of what the tool will do). As I've been learning more about the language I've been coming across a lot of talk about using something like Backbone to structure the code such that it will be easier to read and maintain. While I'm not in love with the idea of taking what I've written and shoehorning it into an MVP paradigm (which would also require me to learn the paradigm), I am in favor of writing quality code that won't cause me headaches later. However, in the course of doing some google research, I've discovered that backbone doesn't seem to play nicely with SVG elements. True, there are some workarounds posted, but it seems to me that if I have to implement a kludgey work-around in order to get everything to work, the value of implementing Backbone in this case is lost as my code is still wonky, albeit in a different way. (ego compels me to point out that as it stands, the code is reasonably un-spagettified)
Given that I'm relatively new to Javascript, and to serious web programming in general, I'm posting this question here in the hopes of soliciting advice from persons more learned than I in matters such as these. If you were in my position, would you implement Backbone (or some equivalent) or would you proceed without it?
I would suggest you keep doing what you are doing. The website looks good and responsive. Do not change anything as long as you think the code is easily maintainable and readable. When you see heavy loading and spaghetti code, then you might consider about using some JS structure.
If the framework manages the HTML/ CSS/ javascript, does a programmer still need to know the javascript language? Or is that taken care of in the abstraction of the framework?
I wanted to make a graphical game/ application using the html5 canvas/ webgl/ whatever other libraries are available to do so. Would it be more effective for me to go through a web framework such as django? I'm not really sure what advantages it offers. I think that if I wanted to create a well designed dynamic site in an effective way, I would use a framework. But if I didn't care about appearance, or if I'm just learning, then am I better off just playing with javascript and html5 first?
In my opinion, you could easily use a framework to simplify your development but remember this: With every framework or tool that simplifies development, you lose a bit of control.
Eventually, you will come to the point where you need to understand css/JavaScript, or whatever the underlying technology is, in order to accomplish some task. In that situation you'll be at a point where you need to learn the "hard" stuff.
Even before you get to that point, however, I'd strongly recommend learning the basics of the underlying technology so that you can see what the tools do. There are many reasons for this, but the most important ones are:
As mentioned previously, sooner or later you'll need to anyway.
If you don't know the underlying technology, you'll struggle and waste a lot of time trying to understand why the pages/apps generated by the framework don't behave the way you want them to.
Troubleshooting is harder
It's really easy for a novice developer to pick up a framework and start doing really stupid things with it. Things that can lead to security holes, leaking sensitive data, exposing yourself and customers to risk.
Some frameworks, of course, protect novice developers from things like SQL Injection, etc, but not all. It takes someone who understands what the tools are doing "under the hood" to tell the difference.
Of course, there is a limit to how much you need to know.
As an analogy, it would be foolish to drive a car without taking the time to learn the basics of how it operates, and how to be safe with it. But to drive a car, you don't need to know how to take apart the engine. If you're one of the guys who wants to be able to take apart the engine (and put it back together), great! You'll be one of the experts in at least one area of the automotive field.
The same goes with development. Different people need/want different depths of knowledge...
But for the web, at least knowing the basics of HTML, css, and JavaScript is a must. It's like learning the difference between Diesel and Gasoline before filling up your tank. It's basic knowledge every web developer needs.
A framework is often developed for the purpose of making larger tasks easier by taking several steps and making them user-friendly. In addition to this, you'll often find that they include configuration files and auto-installers to ease the setup of server components (databases, for instance) so that non-technical users have an ease of use.
The largest issue with this, however, is when users run into errors or warnings that they are unable to debug because the basis for the problem can only be acknowledged with (often) small amounts of expertise in the core languages that the framework was based on.
Quite simply put, you may not need to learn Javascript to use your said library, but it is highly suggested that you understand the inner workings so that you may easily debug and solve problems you have in the near future.
Enjoy and good luck!
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.
Ok this is a bit of a rant and a question combined - Why the hell is magento so reliant on javascript?? This goes agaisnt all usability guidelines. WHats so annoying is that it even uses buttons instead of correct form submit elements. Why? This makes no sense what sense at all to me.
Why is this and is there a way around it?
The past five years have seen an increase of web application developers eschewing the common wisdom of of the late 20th and early 21st century by creating applications and require javascript as a baseline technology. Magento is following this trend because they want to provide a moden, AJAX enabled experience, and providing both a Javascript and non-Javascript experience increases both development and testing time.
Most decisions in the e-commerce industry come down to the ROI of increased sales. Magento has calculated/bet/decided that sales lost due to people having Javascript off are less than the cost of developing both a javascript and non-javascript experience.
As for their use of the HTML button attribute, Magento isn't a web page, it's a web application. Their architecture takes a Java like approach, including a UI that's abstracted away from the browser. This means PHP is used to tame the browser rather than using PHP to work with the browser. In this context button elements (driven by Javascript) make more sense. Take a look at Google Web Tools for another example of this.
The way to "get around" this is to not use Magento, or to customize Magento such that it fits your model of what web development should be. If your first response to this is "woah, that would take way too much time", then congratulations, you're thinking exactly the same way that Magento is. Magento, the company, isn't Microsoft, or Oracle, or SAP. They're a 200 person company, and expecting them to solve all your problems (for free) isn't realistic.
Welcome to 2010.
Magento's JS reliance is unusable in exactly one way: you cannot use the store without it. That's a big one (losing 1/20 of your customers is not a small thing), but ultimately it's a tradeoff that they decided was worth it.
As an example of the flexibility that you get as a result of this decision, consider the case of configurable products, especially with pricing differences. Magento allows you to create products that are configurable over N axes, in a ragged manner (some color/size combinations of clothing can be missing, for example), with different pricing for every single option. Doing that without JS would be tough, doing it elegantly (which Magento has, for the most part), is nigh impossible. By enforcing JS, the developers at Magento, Inc can spend their time implementing these kinds of features more quickly, which is to everyone's benefit.
To answer the question at the end of your post, no you cannot get by without it -- at least without writing a new frontend theme that reimplements everything from scratch, which nobody so far seems to have been able to do. Personally, the number of JS libraries that Magento uses seems pretty heinous to me, but nobody seems to have solved that problem either. The app is too complex and tightly woven to unwind that far.
Sorry it's not better news, but I hope that at least clarifies some of the thinking for the way things are.
Thanks,
Joe
"Why is this and is there a way around it?"
Although the front end uses Javascript heavily it is only essential in a couple of places. Configurable products is one. The one-page checkout is another but that at least can be disabled in System > Configuration > Checkout > Checkout Options.
Buttons with event handlers can be rewritten as a matter of theming, in some cases their destination URL is not the same as their form submission so a little forethought is required. In some cases buttons are not in the form element they are submitting, that is why they use script.
I will assume when considering accessibility you are not concerned about luxuries like image zoom and search suggestions. I notice HTML5 provides the datalist element for input suggestions but some sort of script would still be needed to update it beyond the initial suggestion.
Overall Magento is quite functional without Javascript, just not as out-of-the-box. An 'accessible' theme would make a valid extension should someone want to develop it.
We've just been looking into this when I came across this post (first time we've used the magento platform and our first project with it).
Typically we'd ensure that every site we develop degrades gracefully without javascript, but this is looking like it might be too much work for us on this particular project at least for the first phase (tight deadline alongside steep learning curve).
While I agree that javascript can offer some great usability enhancements, providing a non-javascript fallback isn't just about supporting the odd akward person who insists on turning it off.
Some users using disabled access devices (screen readers etc) as far as I know, might not have the option to use javascript either (or may find javascript interfaces more troublesome to use if not impossible in some cases). In these cases if it doesn't degrade gracefully for them, then I'm a bit concerned that it may conflict with disability discrimination legislation in the UK/EU (where our client operates).
For this reason, I'm not sure we can take the position the magento developers have in the long run (we'll probably end up backtracking and resolving this ourselves ultimately and I'm guessing that will take us longer than if it degraded gracefully from the start and we could simply build upon that).
The admin area is less of an issue, but the front end should work without javascript imho and I was a bit surprised when I discovered that it didn't work without it (the client came to us specifying magento so there isn't much we can do but run with it at the moment).
I think you'll find that the Javascript in most cases significantly enhances the usability. Trying to implement something like the Manage Products grid, Manage Categories tree or Promotions editor without Javascript would be a usability nightmare. When you look at the stats, well over 95% of browsers have Javascript enabled, so what's the problem?
Try using this site with java-script disabled. It works but start counting the post backs and you will see why usability trumps the few folks who insist on disabling java-script.
I'm considering to try out an idea, mostly for fun, and my question is if this is reasonable and if there are any libraries or frameworks that could make this experiment a little easier.
So, the idea: Basically it is to write a new UI for a website I've developed, but doing it with client-side code only. I can read/write data using ajax, since my existing website has an API that allows me to perform all kinds of queries. This allows me to use JavaScript for the whole thing and theoretically put all of the code in a single file.
Obviously there are limitations to circumvent; bookmarking, page refreshing, the back-button etc. But these limitations are what makes it interesting, right? :) I'm not so worried about search engine indexing, since one has to be logged in to use the site anyway.
The site itself is not overly complex, but it is not simple either. There are four different levels of users, multiple languages and quite a lot of data to be presented.
Is this a bad idea? If so, why would you advice against it? And do you know of any JavaScript frameworks or libraries that could make this easier? (And no, I'm not looking for an abstraction like Google Web Toolkit; I would like something purely JavaScript)
One of my coworkers did this. A nice feature of this concept was that you don't have a ton of POSTS whenever the user 'changes pages', since they are actually not ever changing a page until they submit their data for the final time. He did this for product registration software, which was nice. Our servers were only taking a hit when the user initially requested the page, and then when they submitted it.
The major, MAJOR downside to this concept is that most web developers are not expecting this. My coworker (and you) have a cool idea - but unless it is well implemented, with comments, 100% valid HTML, and a host of other good design principles in place, it can be confusing since most web developers have basically never seen this done before. His site was a nightmare to work with, as he did not actually know what engineering web software meant, and it was all slapped together. My organization never pursued this (potentially useful) idea because his implementation was so poor.
So, when I looked at this idea here were the trade-off I came up with:
1.) You cannot require any server-side interaction during intermediate pages.
2.) The initial page loading is longer, but there are no intermediate page requests (better optimization).
3.) This is vastly different than anything anyone usually does, which means you need to be especially careful with documentation.
4.) This design concept facilitates totally stand-alone web software to be easily deployed without the web.
5.) You might be increasing complexity for avoiding page loads, but maybe not. I'm not sure.
All together, I think it just depends on what you want to accomplish. My coworker really just wanted to see if he could do it, which he could. However, how he did it was really pretty bad, to the point where everyone else connected his poor implementation with a poor idea it was fairly sad.
Mostly, I think if you follow good web design practices this wouldn't be too bad of a thing to pursue. What are your goals though?
I'm sorry I couldn't directly answer all of your questions. I hope my experiences are still helpful in answering if I think it is a bad idea or not.
-Brian J. Stinar-
SproutCore is one of the best out there when it comes to really being built from the ground up for single-page, potentially complex applications. Unlike some others like GWT or Cappucino, SproutCore is really about using JavaScript directly. They aren't the only one though. You might also want to look at JavaScriptMVC and qooxdoo.
Personally, I've built an extremely large and complex single-page application using JavaScript. It is currently around 100,000 lines (including comments/whitespace). To give a sense of scale, jQuery is around 6,000. To reach that size, I built my own framework, build tools etc. and it is extremely maintainable. You're asking if it can work, and I can tell you that it does, but you do need a little infrastructure if you're looking at doing something big. (BTW, there's a lot of lazy loading - its not 100,000 lines all at once!)
I also wouldn't really recommend this method for anything other than a web application. As pointed out, its still difficult for SEO, and may be strange for some users.
You're looking for ExtJS
I did my site like that in jquery, backed by spring mvc 3. For me it works fine and you have a lightweight, flashy feling while on it.
If you have time to dig in javascript seriously... it is really good exercise.
The only thing I really need to add is SEO, since spiders see only intial html. If it is important for you, i think backend static files and sitemap would be good enough solution.
I found something very light-weight that provides the basic needed functionally without forcing you into a whole framework. It's called Sammy and is inspired by Ruby's Sinatra: http://code.quirkey.com/sammy/
Very recommended!
Alternative: code the same in Java. Take a look to ItsNat
Think in JavaScript but code the same in Java in server with the same DOM APIs, in server is way easier to manage your application without custom client/bridges because UI and data are together.
Regarding SEO, bookmarking etc in single page there are solutions, take a look to the Single Page Interface Manifesto