It's fall of 2008, and I still hear developers say that you should not design a site that requires JavaScript.
I understand that you should develop sites that degrade gracefully when JS is not present/on. But at what point do you not include funcitonality that can only be powered by JS?
I guess the question comes down to demographics. Are there numbers out there of how many folks are browsing without JS?
Just as long as you're aware of the accessibility limitations you might be introducing, ie for users of screen-reading software, etc.
It's one thing to exclude people because they choose to turn off JS or use a browser which doesn't support it, it's entirely another to exclude them because of a disability.
Two simple questions to help you decide...
Does using javascript provide some
core functionality of your site?
Are you prepared to limit your
potential users to those who have
JS? (ie. Most people)
If you answer yes to both of those, go for it!
Websites are moving (have moved?) from static pages of information to interactive web applications. Without something like Javascript or Flash, making compelling user interactions is sometimes not possible.
Designing to degrade gracefully is the most that should be done. We are moving/have moved past the point of simple web "sites" to web "applications". The only option besides client side scripting to add round trips to the server.
I think (personal opinion) that the "don't use JavaScript" comes more from a lack of understanding of what JavaScript is/does than any actual market data that shows a significant number of people are browsing without it.
It's reasonable to design sites that use JavaScript but it is not safe to assume that all clients have support for Javascript and therefore it is important that you provide a satisfactory experience even when JavaScript is not available
Search Engines don't support JavaScript. They're also blind and don't support CSS. So my suggestion to you is to make sure that the part of your product that needs to be indexable by search engines works without JavaScript and CSS. After that, it really depends on the needs of your users.
If you have a very limited subset of users, then you can actually query them. But to remember that 10% of the population has some form of impairment ranging from vision issues (low vision, color-blindness, etc.) or motor functions (low hand dexterity). These problems tend to be more prominent in the elderly and the knowingly disabled
If your site will target the general audience of Internet users then please make it degrade gracefully, but if you can't do that, then make a no-JavaScript version (like G-mail has).
I think the days of "content sites only" are gone. What we see now is WWW emerging as the platform of web applications, and the latest developments in the browser front (speeding up JS in particular) ar indication of this.
There can be no yes/no answer to your question - you should decide, where on content site<---->web application continuum your site is and how essential is the experience provided by JavaScript. In my opinion - yes it is acceptable to have web applications which require Javascript to function.
Degrading gracefully is a must. At a minimum, you sure make use of the NOSCRIPT tag in order to inform potential customers first that your site requires javascript, and secondly why you require it.
If it's for flashy menus and presentations that I could honestly care less about then I probably won't bother coming back. If there's a real reason that you're requiring javascript (client-side validation on forms, or a real situation that requires AJAX for performance reasons) then say so and your visitors will respond accordingly.
I install extensions that limit both Javascript and Cookies. Websites that don't prominently state their requirements of both usually don't get a second visit unless there's a real need for it.
You should never design a public site to rely on ANY technology/platform. The user agent may not display colour (think screen readers), display graphics (again, think screen readers or text only browsers such as links), etc.
Design your site for the lowest common denominator and then progressively enhance it to add support for specific technologies.
To answer the question directly: No, you cannot assume your users have Javascript, so your site should work without it. Once it does, enhance it with Javascript.
it's not about browser capability, it's about user control. People who install the noscript plugin for firefox so they don't have to put up with punch-the-monkey garbage ( the same problem that inspired stack overflow) will not allow your web site to do anything non-static until they trust you.
In terms of client software consider users/customers who are using a browser that supports some but not all Javascript. For example, most mobile phone browsers support a bit of Javascript but nothing very complicated. The browsers on devices such as the Playstation 3 are similar.
Then there are browsers such as Opera Mini, which support a lot of Javascript but are operating in an environment where the scripts are running on a server that then sends the results to a mobile device.
You should design websites with Javascript in mind--but not implemented. Consider, build it where every click, every action, performs a round trip to the server. That's the default functionality for older browsers, and those without JS turned on.
Then, after it's all built, and everything is working properly, add in JavaScript which hijacks the link, button and other events, and overlay their standard functionality with the Javascript functionality you're wanting.
Building the application like this means that it will ALWAYS work, which ultimately is what you're wanting.
The received wisdom answer is that you can use JavaScript (or any other technology) providing that it 'degrades gracefully'...
I have experience with disability organisations, so accessibility is important to me. But equally, I'm in the business of building attractive, usable websites, so javascript can be a powerful ally. It's a difficult call, but if you can build a rich, javascript-aided site, without completely alienating non-js vistors, then do so. If not, you will have to look at the context of the site and decide which way to jump.
Regardless, there are no rights and wrongs with this question. However, in some countries, there is a requirement to build 'public' sites to be accessible, so this may be yet another factor in your decision. [In the UK, it is the Disability Discrimination Act.. though to my knowledge, no company has been prosecuted for failure to comply]
JavaScript is great for extending the browser to do things like google maps. But it's a pointy instrument, so use it with care.
My bank web site uses JavaScript for basic navigation between pages. Sigh. As a result, it's not usable from my mobile device.
Make sure you're familiar with the Rule of Least Power when considering JavaScript:
When designing computer systems, one
is often faced with a choice between
using a more or less powerful language
for publishing information, for
expressing constraints, or for solving
some problem. This finding explores
tradeoffs relating the choice of
language to reusability of
information. The "Rule of Least Power"
suggests choosing the least powerful
language suitable for a given purpose.
5% according to these statistics: http://www.w3schools.com/browsers/browsers_stats.asp
As you said, demographics. The web is expanding onto devices that doesn't have very much power, for instance cellphones. If your site is usable without javascript, Opera Mini will likely show your site without any problems.
I think Javascript implementations in most modern browsers have now reached a reasonable level of maturity and there are a bunch of Javascript UI frameworks which let you build very attractive Javascript based web applications using web-services and such (regardless of the back-end server platform).
An example is ExtJS - they have got a very extensive AJAX + UI widget framework which I recently used to build a full fledged internal web-app for a client with an ASP.NET backend (for webservices).
I think it comes down to what you're about to do. Are you writing a web APPLICATION? Then I think you're bound to use javascript and/or something like GWT. Just have a look at all the social sites, and google aplications like gmail. If you're writing a webpage with product descriptions and hardly any interactivity, then you can make the javascript optional.
I agree with the majority of the stackoverflow respondents. JavaScript has matured and offers an "extra" level of functionality to a webpage, especially for forms. Those who turn off cookies and JS have likely been bitten while surfing in dangerous waters. For the corporate power users that pay my way either in B2B or retail sites, JS is a proven and trusty tool. Until something better comes along (and it will) I'm sticking with JS.
There's addon for Firefox called NoScript which have 27,501,701 downloads. If you site won't work without JavaScript most of those guys wouldn't want to use it.
Why you would install that addon? Ever wanted to get rid of the popup on the site that cover the most of the useful text you want to rid? Or disable flash animation? Or be sure that evil site won't steal your cookies?
Some corporate environments won't allow Javascript, by policy or by firewall. It closes the door to one avenue of virus infection.
Whether you think this is a good idea or not, realize that not everyone has full control over their browser and it might not be their choice.
There is a gradient between web sites and web applications. However, you should alway be able to say "we are building a web site" or "we are building a web application".
Web sites should be readable down to plain HTML (no CSS, no images, no JavaScript).
Web applications, of course, could just say "Sorry, JavaScript is needed" (which also assumes CSS for layout). Application should still be able to work without images.
The accessibility issue is the only important technical issue, all other issues can be socially engineered. When one says that javascript reduced accessibility and another says that Web Applications can use javascript, can we take these two together to imply that all blind people are unemployed? There has to be some kind of momentum in making javascript accessible. Maybe a Screenreader object on the javascript side which can detect the presence of a screenreader and then maybe send hints to the screenreader, Screenreaders which can hook onto the browser, and maybe it gets glued together with a screenreader toolbar.
if you want your site viewable by the top 100 companies in the US. I would write without javascript.
Independence from Javascript and graceful degradation are important to an application despite the actual demographics -- because such an application probably has better software design.
The "human user without Javascript" may be purely hypothetical (for example, if you're trying to make money with your product). But designing for that hypothetical user encourages modular software design which will pay off as you continue to develop your app.
Javascript provides functionality. HTML provides data (on the page itself, and via links that point to more data). As a general rule that reaches well beyond browser apps: A well-designed software product will separate data from functionality. All data should be available, and the functionality should be a separate layer that consumes the data.
If your Javascript is creating data at runtime, then it's time to get specific and figure out whether your webpage really is a piece of software (e.g. a mortgage calculator) or whether it's a document containing data (e.g. a list of mortgage interest rates). This should tell you whether it makes sense to rely on Javascript.
As a final note/example, demographics can be misleading. Relatively few humans browse your site without Javascript, but lots of machines (search bots, data miners, screen readers for the disabled, etc.) are browsing your site without Javascript. Again, the distinction between data and functionality are important -- the bots are just making requests and looking for data in the responses. They don't need functionality. But if your user needs to invoke functions just to make your data accessible, the bots are getting no value from your site.
One side point about the screen readers and other accessibility considerations for the disabled. This is an important niche demographic: a mind that navigates data in a human way, but who can only get data from your site in the same way machines get it. By providing data cleanly and semantically on your page, you make it available to the largest possible set of accessibility tools.
Note this doesn't exclude Javascript from consideration. Our mortgage calculator example can still work: accept input from the user, invoke Javascript, and write the output back into the clean semantic data layer of the page. Screen readers can then read it! And if they can't, you're encouraging the development of better screen readers that can.
If you expect your app to work for everyone, you'll need a backup for all your javascript functionality. If it's form validation, you should also check the data on the server before saving it. So the answer is Yes, it's okay, but have a backup. Do not rely on it.
As many people are saying, it's important to consider your user base, but whoever your users are there's a strong possibility that some (stats say 10%) of them will have some sort of disabilities, and screen readers don't like javascript. If you're only adding simple things, a javascript menu or something, then just make it degrade (or don't do it). If the site depends on javascript to work properly, make two versions, one for javascript and one without.
I generally find that anything too javascript heavy is very difficult to make degrade well without just having javascript re-writing the page to a javascript version if the user can take it. Given this, it's well worth writing two pages from square one for complicated stuff.
I would say that there are very very very few web sites that should be running without some support for users without javascript. You'd need to have a very dynamic application that completely didn't make sense as static pages,or you'd need to have a audience you could guarantee were ok with it (like on an office Intranet say).
Well, it depends on your userbase. If you know that people will be using your site from mobile devices, it's good to have unobtrusive JavaScript. However, if you're trying to appeal to a tech-savvy crowd, don't bother with it.
However, if you're appealing to a crowd that may be using screen readers (blind people), I'd highly suggest using WAI-ARIA standards. Dojo's widget system has full support for this, and would be a great and easy way to do it.
Anyway, in most cases, you don't need unobtrusive JavaScript. Most people who have JavaScript disabled are either using a smartphone, using Lynx, or have NoScript installed. It's enabled by default in all the major browsers, so you shouldn't have to worry.
Lastly, it's good to at least have some unobtrusive JavaScript. <noscript> tags are your best friend. For example, one may want to replace a widget that draws rating stars with text. Example using dojo:
<div dojoType="dojox.Rating" stars="5" value="4"></div>
<noscript>4/5</noscript>
It's the 21st century. People not permitting JavaScript need to exit the last millennium, posthaste. It's a mature, widely used, and very useful technology that is one of the foundations of the recent expansion in useful web services.
You should be tying the functionality of your website to your audience. That being said, every modern browser (save for the mobile platform) includes javascript, and so unless your audience includes luddites with decade old computers, you can assume they have javascript.
The people you need to worry about, then, are those that specifically turn it off. This includes:
Corporate networks with tough security (not common, but some financial and defense institutions)
Paranoid web-heads
So, first, who is your audience? Are there other websites that are comparable to your target? Look at their site and success - do they degrade gracefully, and would yo be satisfied with their level of success?
If you are targeting mobile applications, though, you can't guarantee javascript.
-Adam
I would say that you should look at your target audience. If you can reasonably expect that they will have js enabled, and making everything work without any js is too much of a pain, then by all means - go ahead and ignore the non-js crowd, if, on the other hand you have to create a site that will be used by a very large audience/or you are perhaps building a government web site, then you must make sure that everything works, and it is easier in those cases to first build the site so that it works without any js, and add all the nice time-saving ajaxy bits later.
In general though, almost everyone has js enabled by default.
Though you should be aware that server-side validation of user posted data is a must in either case.
Related
I know from an historical perspective that it has always been frowned upon to not gracefully degrade when a visitor with Javascript disabled visits a site but how relevant is this now?
I'm asking since an application I'm building is going to make heavy use of Javascript for charting and user interaction with the charts.
Most of the most popular sites on the web are rendered more or less useless without it enabled. I can't even login to twitter without it enabled, core bits of Facebook stop working and trying to visit Google maps just redirects to their search home page.
The kind of interaction I'm planning would be next to impossible to do any other way, and even if there was a way there isn't the resources to develop two versions of things.
The problem I have is that the site also needs to be as accessible as possible. It's an inherently visual site which makes this problematic to say the least. I'm not even sure there is a solution to this particular problem. If it's visual it's not going to be suitable for blind people.
This depends entirely on your needs and what you want your demographic to be. A lot of sites use exclusively flash to silverlight; does that make them poorly designed? No. All it means is that the site caters to a very specific audience.
As long as you are accepting that there may be a (albeit) small populous that aren't going to use the site (or can't due to missing support) then it's fine.
Side-note: there are other means of conveying graphics other than javascript. Using server-side image generators is one way. You may also decide to use flash/silverlight plugins or activeX/applets. My advice would be to design the site as you see fit.
I would bet that the amount of javascript support these days is in the majority, so creating the site first then working on the discrepancies later wouldn't be a bad avenue. Youre still going to receive a high saturation of visitors just on the assumption that most clients support it.
Heck, look at sites using html5--it's not a standard, and no browser has to support it, but this still doesn't stop people from taking advantage of article, header & footer elements. Granted, there is html5shiv to gracefully down-grade it, but even that depends on JS being present.
Javascript has become so thoroughly integrated with web development that it is now users that browse without Javascript that have become a novelty.
What you should do is put up a friendly message that informs the user that the specific service your page provides (charts etc.) cannot be provided without JS enabled, and leave it at that.
What I would worry about is thoroughly detecting feature compatibility, because while people with JS disabled aren't that common, people with ancient browsers are.
Since you tagged this with accessibility, I will cover that perspective. As others have said, Javascript is part of something that we live with. While it isn't expected that the application can be made fully accessible to people with visual imparments, you have to keep in mind other disabilities as well such as mobility imparments. WebAIM has an article about what to keep in mind when you are coding JS events to make it as accessible as possible.
Depending on what these charts do, you should put the resulting data in an accessible table at the very least either somewhere on the page or a link to the data/table in proxcimity of the graph, so that it is easy to find for those who need it.
You didn't specify who you are making this for, so I will give some more information. Gez Lemon wrote an article about not using <noscript>, his summary is:
I'm surprised that the noscript element is conforming in HTML5, as there are much better techniques for ensuring that pages work with or without JavaScript. Despite early accessibility advice advocating use of the noscript element, best practice is to use unobtrusive JavaScript for progressive enhancement, rather than relying on fallback content.
This sort of echoes what I began my answer with. However, if you are doing this for a US or state government agency, you must still use <noscript> tags because it is a requirement of Section 508. The information with the <noscript> tags should be useful. EX:
<script type="text/javascript">
// Do something cool
</script>
<noscript>
Please perform your search again using the <a>javascript-free form</a>
to get the results in a table.
</noscript>
I've been investigating a few of the JavaScript frameworks such as Backbone.js and Batman.js for a while and whilst I really like them, I have one niggling thing that I keep coming back to. That issue is accessibility.
As a web developer I've always tried to make my websites and applications with accessibility in mind, especially using the idea of progressive enhancement.
Clearly out of the box these new JS frameworks don't gracefully degrade, so I was wondering what are other developers thoughts on this issue and what are you doing about it. After all the accessibility of a website / app isn't really an optional thing as it's part of the law in many countries.
Maybe I'm just being overly zealous on this subject, and not appreciating how far things have come in terms of accessibility.
I use a js-framework (spine.js in my case) in my latest site. Still I make sure that non-js browsers (certainly not over zealous: think SEO) can navigate my site and digest the contents.
As an example I'm going with a search-page with products being shown. Products can be paged, filtered, sorted. Of course this is an example of the generalized idea.
PREREQ: use a template-engine that can both render server-side and client-side. (I use Mustache) . This makes sure you can render models without js- through server-side templating, and render models with js through client-side templating.
Initially: render the products using server-side mustache-template. Also include a 'bootstrapJSON'-object which contains the same products in JSON-format.
Initially: all links (product-detail page, paging, sorting, filtering) are real server-side urls (no hashbang urls)
The end-result is a page which can be navigated 100% with paging, sorting, filtering without the use of JS.
all paging,sorting, filtering urls result in a request to the server, which in turn results in a new set of products being rendered. Nothing special here.
JS-enabled - on domload:
fetch the bootstrapJSON and make product-models from it (use your js-framework features to do this) .
Afterwards rerender the products using the same mustache-template but now doing it client-side. (Again using your js-framework).
Visually nothing should change (after all server-side and client-side rendering was done on same models, with same template), but at least now there's a binding between the client-side model and the view.
transform urls to hashbang-urls. (e.g: /products/#sort-price-asc ) and use your js-framework features to wire the events.
now every (filtering, paging, sorting ) url should result in a client-side state-change, which would probably result in your js-framework doing an ajax-request to the server to return new products (in JSON-format) . Rerendering this again on the client should result in your updated view.
The logic part of the code to handle the ajax-request in 6. on the server-side is 100% identical to the code used in 4. Differentiate between an ajax-call and an ordinary request and spit out the products in JSON or html (using mustache server-side) respectively.
EDIT: UPDTATE JAN 2013
Since this question/answer is getting some reasonable traction I thought I'd share some closely-related aha-moments of the last year:
Spitting out JSON and rendering it client-side with your client-side mvc of choice (steps 6. and 7. above) can be pretty costly cpu-wise. This, of course, is especially apparent on mobile-devices.
I've done some testing to return html-snippets on ajax (using server-side mustache-template rendering) instead of doing the same on the client-side as suggested in my answer above. Depending on your client-device it can be up to 10 times faster (1000ms -> 100ms) , of course your mileage may vary. (practically no code changes needed, since step 7. could already do both)
Of course, when no JSON is returned there's no way for a client-side MVC to build models, manage events, etc. So why keep a clientside MVC at all? To be honest, with even very complex searchpages in hindsight I don't have much use for client-side mvc's at all. The only real benefit to me is that they help to clearly separate out logic on the client, but you should already be doing that on your own imho. Consequently, stripping out client-side MVC is on the todo.
Oh yeah, I traded in Mustache with Hogan (same syntax, a bit more functionality, but most of all extremely performant!) Was able to do so because I switched the backend from java to Node.js (which rocks imho)
Since I'm a visually-impaired user and web developer, I'll chime in here.
These frameworks, in my experience, haven't been a problem provided the appropriate steps are taken with regard to accessibility.
Many screen readers understand JavaScript, and we as developers can improve the experience using things like HTML5's aria-live attribute to alert screen readers that things are changing, and we can use the role attribute to provide additional hints to the screenreaders.
However, the basic principle of web development with JavaScript is that we should develop the underlying site first, without JavaScript, and then use that solid, working, and tested foundation to provide better features. The use of JS should not be required to purchase a product, receive services, or get information. And some users disable JavaScript because it interferes with the way their screenreaders work.
Doing a complete Backbone.js or Knockout site from the ground up without regard for accessibility will result in something akin to "new Twitter" which fails extremely hard with many screenreaders. But Twitter has a solid foundation and so we can use other means to access the platform. Grafting Backbone onto an existing site that has a well-crafted API is quite doable, and an awful lot of fun, too.
So basically, these frameworks themselves are no more of an accessibility issue than jQUery itself - the developer needs to craft a user experience that works for everyone.
Any webpage that requires javascript in order to get the content out of it will likely be met with accessibility-related challenges. The accessibility of JavaScript frameworks is definitely an issue of contention, though really, any web application suffers drawbacks when content is provided dynamically, regardless of the framework used.
There's no silver bullet to ensure your site will be accessible, and I certainly can't account for every JavaScript framework. Here's a few thoughts about how you can prevent your site from being totally inaccessible when using JavaScript:
Follow the guidelines from WCAG 2.0 on client-side scripting, and WCAG 2.0 in general.
Avoid frameworks that require you generate the page's UI, controls and/or content entirely through javascript such as Uki.js, or ones that use their own proprietary markup, like Jo. The closer you can stick with static(-ish), semantic HTML content, the better off you'll be.
Consider using ARIA roles such as role="application" and the aria-live attribute to indicate the areas of your page which are dynamic. More and more aria roles are being supported by assistive devices as time goes by, so using these aria attributes makes sense when you can add them to your app appropriately.
In terms of JS libraries, check their source and see if they output any aria roles. They might not be perfectly accessible, but it would demonstrate they're considering assistive devices.
Wherever possible, treat JavaScript as an enhancement rather than a necessity. Try to provide alternative methods or workflows to accessing the important information that don't require dynamic page updates.
Test and validate your app with your users! Do some user testing sessions with people who use assistive devices or have other difficulties using web software. Nothing will help you prove your site is accessible more than watching real people use it.
The last point is the most important, though many try to escape it. Regardless of the technology, the fact remains that you're developing an application that people will use. No machine or theory will ever be able to perfectly validate your application as being usable, but you're not building it for machines anyway. Right? :)
Chris Blouch (AOL) and Hans Hillen (TPG) had a good presentation on this regarding jQuery, including the work they do in reviewing for accessibility. Making Rich Internet Applications Accessible Through JQuery That and another related presentation on Accessibility of HTML5 and Rich Internet Applications (http://www.paciellogroup.com/training/CSUN2012/) should be of interest to you.
My money is on choosing the most accessible framework: jQuery provides a great deal of graceful degradation or progressive enhancement fallback as well as an overall pretty good focus on accessibility. Also, indirectly I help test and review several systems that leverage jQuery (Drupal public and Intranet websites) such that defects found for accessibility are found and routed back to the project for fixes.
Is it still bad practice to create a website that relies on javascript?
I know it used to be, but nowadays most browsers support them... Why or why not should I worry about this?
Spending extra effort to make a site work without Javascript is becoming increasingly ridiculous when so much of the web breaks when you disable it.
For example, did you know that you can't install Google Chrome when you're using a browser without Javascript? Their "accept and install" button requires Javascript.
You should, of course, use the <noscript> tag to display appropriate messages to the user that may have accidentally disabled Javascript in their browser. Google places this text at the top of their page via the noscript tag:
You need a JavaScript-capable browser
to download this software. Click here for instructions on how to enable
JavaScript in your browser.
I admit this was a surprising case when I discovered it, because well... it's Google. And millions of people have downloaded Chrome. But I think it illustrates the point that a site dependent on Javascript is a pretty normal thing today.
Depends on the target audience, but more importantly how you're using JavaScript.
Using it for effects that don't interfere with any actual functionality is usually fine.
If you want to target a broad audience and your website is non-functional without JavaScript, then you may want to reconsider.
No modern, interesting, web application does not use JavaScript. A content-only site might not use it, and any web site should warn the user that JavaScript is required, but it's been a long time since "no JavaScript" made any sense.
Search engines still do not evaluate JavaScript. If you want your site to be indexed, all the content needs to be accessible without JavaScript.
It's not bad practice to rely on JavaScript, but I would say it's bad practice to assume without checking that JavaScript is enabled.
At the very least your website should give the user a nice error if JavaScript is disabled. Ideally, at least the basic functionality (such as text content and images) should still work and JavaScript should enhance it: see Unobtrusive JavaScript.
You should know your target audience of course. If you know that everybody will be using a certain browser for something like an intranet application then you can probably assume that they will be using JavaScript.
If you are writing an application for the general public, then I would take extra effort to write it such that it works without JavaScript. Then use JavaScript to enhance the existing solution. It takes extra effort, but you can make an application both accessible and interesting if you try.
EDIT: Also thought I would add since I haven't seen any references to it, but building a website that relies on straight JavaScript (and not a common JavaScript library like JQuery) would be unwise. JQuery helps you address some of the browser differences that made JavaScript so problematic a few years back (not to mention doing more with less code).
The new HTML5 standard, which many browsers are already starting to support, relies pretty heavily on scripting for much of its new APIs. So no, it is not bad practice to use scripting, it is encouraged.
If you're making a website that's available on the internet and whose audience is more than just people you know, then it's absolutely not OK to build it so that it doesn't work without JavaScript. Many people and corporations choose to browse the web with JavaScript turned off, for many reasons, and you need to remember that the majority of users are not developers and do not browse the web in the same way with the same tools as you.
Use progressive enhancement: start by creating and testing all the core functions of your site with simple HTML. When that works, add JavaScript functionality.
Developing a highly interactive web application is a different matter. For that, it's not unreasonable to insist on your users using particular browsers with JavaScript enabled.
How important is it to gracefully degrade or inversely Progressively Enhance the UI experiance? I mean am I going to lose a LOT of business if I don't? Do you practice this concept? Are there any web 1.0 users still left out there?
Please could you also include if you practice this personally and how much time you've spent relative to the entire project. I realize every project is different, I want to get a sense of how much time as a general rule I should be allocating toward this goal.
EDIT
Firstly, i'm looking for guidance around how much time I should be devoting to making my applications run without javascript.
Secondly, the BS term "web 1.0" (...lol... I don't really like it either) works because we all understand that as the iteration before ajax and all its goodness.
Thirdly, the kind of applications I'm describing are the ones we are all building, not Facebook, not Twitter (unless you're from Facebook or Twitter) but service or utitlity programs like a web calendar, or an online todo list or [INSERT YOUR APP HERE].
Progressive enhancement is more a mindset than a particular task that you need to allocate time to. If you're doing it right (and if it's important to you), you should be enhancing the user experience with JavaScript, but not relying on it.
For example, a link will point to a new page, but with JavaScript you'll disable the link and load new content into the current page with Ajax. Start off without JavaScript and progressive enhancement will follow naturally.
Progressive enhancement is not only smart but it is faster and easier to develop.
And at each stage, you almost always have a working fall-back.
Here's what it looks like in a nutshell:
Boss/client approves mock ups.
We code to valid HTML output. At this point, the boss/client can start using the site. Baring any boss/client changes, the HTML is mostly done. The site is usable at this point.
We start tweaking the CSS to make it match the boss/client's graphic expectations. Changes to the HTML are minor, if any.
In parallel, JavaScript is added to do non-critical, but nice, things. (Sort tables, Fancy CSS helping, replace some links with AJAX calls, warn the user -- client-side -- of input problems.)
If any one of these things breaks, the site still works.
Also, little, or usually no, html changes are needed.
First of all, lets not start using bullshit terms like "web 1.0" and "web 2.0" etc, the fact is the web is forever progressing and new websites are starting to use JavaScript to enhance the user experience.
I don't know anyone that doesn't allow their site to gracefully degrade when JavaScript isn't available, this is for the same reason we use semantic markup so screen readers can correctly interpret our websites for users with visual impairment, and whilst the vast majority of your visitors / users won't fall into these categories it's still important to think about the minority.
Will you lose a LOT of business, well that depends on how successful you are now and how badly your site degrades, chances are you probably won't lose any business... but that should not be the measure yo use to decide whether to gracefully degrade a website.
So unless you can come up with a pretty good reason, you should probably use JavaScript for the purposes of progressive enhancement, don't depend too much on it.
:-)
This greatly depends on the nature of your aplication and its data. If it's something that you know will be mostly used via computers, than degrading to non-script version UI wouldn't make any obvious benefit (even loss of money because it will take considerable time to develop). You can always tell people to enable javascript in their browsers (similar to what's done here on Stackoverflow - try disabling script and reload the page). Your app/site should display at least something when there's no Javascript posibility.
But if your application has simple data to display and users should access it frequently wherever they are, than degrading to lesser browsers (without script engines like Opera Mini) is a must. Creating a separate UI will less functionality, but keeping everything in that users need to access is probably your best option. UIs like separate iPhone applications for example...
JavaScript is disabled by a small proportion of web users, but when you start to talk big volumes this can make a difference. For example for 1 million visitors, you can expect more than 10,000 not to be able to user your site.
You should decide how much lost business is worth the additional cost of having a non-JavaScript version of your site.
You can have an approach where the entire site may not work without JavaScript but that some of the core features are there.
Many years back, I was told that Javascript was harmful, and I remember being annoyed with endless popup when I right-clicked an image to download it.
Now it seems suddenly that Javascript is great, and you can do a lot of things with it to let users have native-like web application experience.
I admit I have missed 6-7 years of Javascript literature, so I hope to start anew with SO kickstarting me to understand the following:
Is Javascript mainly concerned about user interface i.e. smoothen interaction between application and users and not about logic processing, number crunching or form processing etc.?
Can Javascript write to local hard drive (besides cookies)?
Can Javascript web application run with Javascript capabilities in browsers turned off? (I would think outright no, but an article on Adaptive Path said 'maybe')
Is AJAX illegal to use due to Eolas patent claim? Is it worth it spending effort learning it when the future is not secure? (I know AJAX is not Javascript)
Thanks. Hoping for enlightenment.
Yes. JavaSscript is usually used to enhance the user's experience and make the site easier to use. It is also possible to delegate validation tasks and the like to JavaScript, however (though this should never absolve the server of its responsibility to check input).
No.
That depends on how the application is written. If it's done properly, then the JavaScript will merely enhance the interface, and the application will still work without it; this is called progressive enhancement.
Not at all. AJAX is used extensively on this very site!
One reason for the resurgence of popularity for JavaScript lately is the emergence of several frameworks. These make the process of writing JavaScript much, much easier, allowing tasks that would previously have been horribly complex to be implemented with minimal time and effort. The most popular of these is jQuery, which is a good place to start if you're intending to get in on the action.
Overall, JavaScript is a very powerful tool that allows you to create very rich interfaces. Well worth learning.
Yes, Javascript is all about client side processing, but also about AJAX where it calls back to the server asynchronously so that users do not see pages reloading.
No
No, but there are ways to gracefully degrade the experience for non javascript users. It requires carefult planning however.
No, that lawsuit was just about the browser technology that enables it. As a developer you dont have to worry about that.
Can Javascript write to local hard drive (besides cookies)?
Not really. However, as HTML5 support becomes more widespread you'll be able to use things like Web Storage and Web SQL. You won't be able to write arbitrary files on the user's hard drive, but using those two technologies you'll be able to persistently store and access data.
Can Javascript web application run
with Javascript capabilities in
browsers turned off? (I would think
outright no, but an article on
Adaptive Path said 'maybe')
It really depends on how you define "web application." You can write web apps without using Javascript for anything but UI candy, in which case you can degrade gracefully without without it. However, it's also possible to write web apps that rely heavily (entirely, even) on Javascript, which will utterly fail without it.
Is AJAX illegal to use due to Eolas
patent claim? Is it worth it spending
effort learning it when the future is
not secure?
I'm not a lawyer, but I'd agree with the other answers -- you shouldn't worry about it. I'm certainly still writing AJAX stuff :)
Is Javascript mainly concerned about
user interface i.e. smoothen
interaction between application and
users and not about logic processing,
number crunching or form processing
etc.?
It's about both. And more than that.
Javascript has really come into its own in the past few years. Browsers have gotten a lot faster at executing it quickly, and people have been figuring out new ways to use the language itself to its full potential. You can really start using Javascript like a full-out application programming language, and not just to write little scripts that animate something or validate input.
If you're just getting back into the language and haven't read Crockford yet, I would highly recommend it. It's a great starting point to realizing the full potential of Javascript.
Edit: Some good Crockford Links
Javascript: The World's Most Misunderstood Programming Language
Javascript: The Good Parts (This is a presentation. Crockford also wrote a book by the same name that I haven't read myself, but I hear it's quite excellent.)
It's mainly for UI, but it can be used to save server-time on some operations (for example, Mathoverflow uses it to render LaTeX) and it's becoming popular to do so. But when you do this, you need to be respectful of the end-users time, because JavaScript can hold up some browsers, while it runs. But in general, it's a good and interesting idea.
Not without permission
If it's written correctly, it can. It's called "Graceful degredation" (some other variant terms exist, but the idea is the same). The basic idea is that you have it such that the JavaScript fails 'gracefully', and links that would normally get handled via JavaScript (i.e. to do some inline next-paging) will navigate to a 'backup' page that shows the relevant content.
I don't know about that, but AJAX can be implemented in different ways, XMLHTTPRequest is just one of them :) (And the most common, and suitable). Generally you like a library do this for you anyway (jQuery, or otherwise) but you can do it yourself for fun.
Yes, in my experience JavaScript is generally used to create a streamlined interface and relays information from the client to a server application for processing.
Yes, if the browser is configured to allow this (most aren't by default since this can be very dangerous).
No, JavaScript will not run if the browser is configured to have JavaScript disabled.
I wouldn't forgo learning JavaScript for this reason - as for the legality of the whole thing I wouldn't feel comfortable advising you about this. Still I think JavaScript is worth learning in spite of this situation.
The Eolas patent covers the embedding of objects in a HTML document (see US patent 5,838,906 titled "Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document") ... this scope would not seem to include AJAX as a suite of technologies (being essentially scripting in a document to load content elements).
Partial answers:
I think all the security vulnerabilities associated with javascript have been fixed? IIRC the problems weren't with javascript, they were with particular browser's implementation of javascript.
I wouldn't worry about any patent claims on the AJAX technology. Patent sueing and counter-sueing is common place in the software world and invariably ends up with the affected parties licencing each other's technology. AJAX is not going anywhere :)