Will browsers that use HTML5 use less JavaScript, jQuery, etc. and make things like animations done with just HTML? Will it make Flash less necessary for “smooth” graphics?
In other words, I won’t lose anything by taking the time to learn jQuery since HTML5 is here, will I?
In some specific places, yup:
The autofocus attribute is specifically designed to replace a common JavaScript pattern
CSS3 animations can replace JavaScript animations, so if we’re talking about HTML5 in the expanded Apple sense of the word, yup
But in general, I can’t see HTML5 diminishing the usefulness of JavaScript, nor frameworks like jQuery, one bit. Given that HTML’s development is constrained by browser releases, the best it can do provide markup alternatives to a few very common scripting patterns. Scripting is useful because it lets you do anything you can imagine, including things specific to the project you’re working on.
So learn away.
Well, it potentially can mean quite a lot more scripting. For example, where before you might have stuck a flash object into your page to display a chart or graph, that graphic might now be done using javascript drawing to a canvas. Overall I dont see the use of client side scripting decreasing, but rather increasing as web 'pages' become more and more complex. HTML5 will just provide even more possibilities.
HTML is about content. If you want to add behaviors to it you will still need JavaScript. Just like you will still need css to apply a layout.
Learning JavaScript will definitly be time well spent.
HTML 5 is ratifying the use of EMCAScript (a.k.a. JavaScript) to a degree that no prior W3C standard has done.
Some will say, in the future, that this was the harbinger of the decline of modern civilization.
In some ways, yes. This is especially true with regards to form elements. New input types are available, which include things like url and email. There are also min and max attributes, and a required attribute. These have the potential to greatly reduce the amount of work involved in building a front-end web form. Server-side validation will still be necessary, of course, but there will eventually be less need for duplicate code on the client side.
No. You still have to code fallbacks for browsers that don't support the HTML5 features you're using. The fallbacks will contain the same amount of Javascript code.
Related
This is more of a question of style and preference than anything, though it's possible that there might be performance considerations as well.
If you're using a framework (say jQuery for the sake of argument, though it could be any framework) and you need to write a new function. It's a simple function, and you could easily accomplish it without using the framework.
Is there an advantage to using the framework anyway, because it's already loaded in the browser's memory, has a readily-accessible map of the DOM, etc.? Or will plain-vanilla js always parse faster because it's "raw" and doesn't depend on the framework?
Or is it simply a matter of taste?
The answer is going to depend greatly on what you're working to accomplish. In general, you're guaranteed at least a minor performance penalty for function overhead if you use a framework to achieve something that can be accomplished using "vanilla" JavaScript. This performance penalty is typically nominal and can be disregarded when taking other advantages of your framework into mind (speed of development, cleaner code, ease of maintenance, reusable code, etc).
If you absolutely have to have the most efficient code possible then you should try to write pure JavaScript that's highly optimized. If, like in most real world scenarios, you're not concerned about a handful of milliseconds in performance difference, stick with your Framework to maintain consistency.
There's always something to learn when you're solving problems with pure JS as opposed to having external code do it for you. In the long run, it's more maintainable because it's your code. It's not going to change. You know what it does. That's where the value of solving your own problems really comes into play. If you do your research on MDC, MSDN, and the ECMAScript spec, cross-browser scripting becomes a lot easier to process. Sure, Microsoft has their own ideas and their own DOM, but that's where the fun (read: challenge) is.
Cross-browser scripting in pure JS really heightens your problem-solving ability along with your understanding of the language. If there still are things that confound you, then jQuery can come into the mix and bridge the mental gap, so to speak. It's great to drive around in a luxury vehicle, but what use is it if you don't know how to change a tire when it goes flat? The best jQuery devs are the ones that know JavaScript well and know when to use jQuery, and when to use plain JS.
Sometimes, you just have to roll up your sleeves and do some hard work. There isn't a jQuery plugin for everything, and jQuery can't hide you from all the quirks that various browsers have to offer. Getting the job done with your own code is very rewarding, even if you had to sweat it out to make it work.
It's perfectly acceptable to use many different tools to complete a singular task. You just need to know when and where to use them.
From my understanding of jQuery it doesn't actually maintain a map of the dom in Memory and just has cross browser methods for walking the dom. Somethings will natually be faster in some browsers over others (such as a class based selector in Firefox will be faster than in IE because IE doesn't have a built in function for getElementsByClassName and Firefox does). If you don't need the frameworks methods for doing things I would say go ahead and use the native JS as that is generally what you chosen framework will use.
I would say do it with the framework, just because it will bring consistency inside the project. If you are using the framework everywhere even in small function, it will be easier to maintain.
As for the other factor it really depends on what you are trying to do.
I've been working on a javascript-heavy project. I've found that almost every time I had a cross-browser bug in my code, it was in a place where I had code like this:
var element = $(selector);
// lots of code ...
element[0].someVanillaOperation();
and that vanilla wasn't exactly the same across all browsers. What I love about jQuery is that (most of the time) it hides the browser differences and its functions work the same across them all.
If you're selecting elements by ID then plain Javascript is faster. It doesn't, however, provide any of the selection niceties that you get with jQuery - selecting multiple elements by class in a single call, for example.
Take a look at this link: http://www.webkit.org/perf/slickspeed/ which runs a speed test. It's an older version of jQuery, but the results in terms of raw speed speak for themselves.
Personally, I tend to use jQuery for everything - it keeps the code cleaner and the fact it pretty much dispenses with cross-browser JS support issues is worth any performance overhead in my book.
Honestly, now when we have so many javascript features on the frontend I really wish javascript in the browsers could replace html and css entirely.
We could deal with objects (structure + design + functionality) instead of html elements and css that style these elements.
But since that is never going to happen, I wonder if there is any low-level framework that abstracts away html and css entirely, like node.js (not high-level like Sproutcore) but for the frontend?
I think that would be the next big thing :)
I think that a framework that abstracts away html and css, would by definition, be high level. So you are asking an invalid question.
I consider these all high level frameworks, but they are the only ones I am aware of that abstract away html and css.
qooxdo
gwt (Google Web Toolkit)
pyjamas
cappuccino
This would've been easy if all browsers follow a strict standard. So the case now is that you will eventually find yourself needing to tweak the "low-level" javascript/css to make it compatible to all major browsers.
JQuery already gives an abstraction to cross-browser compatibilities but still considered low-level in your definition since you will still need to manipulate elements by yourself.
There are many attempts to "objectify" at least html, especially when using Java and server-side programming which includes Wicket, Groovelets and the aforementioned GWT to name a few.
Gwt does that using Java. So all you have to do deal is with java objects and the tree that make to contain other objects. Though with UI binder they have kinda brought back the old html.
And going by the limited reading of Sproutcore, GWT does something similar too. GWT can be used to make server sessionless i.e. it doesn't recognize the user but only serves the data.
In my project we are using GWT to have business logic coded in GWT which asks for data which the widget require from server.
Try Google Closure Library. Its a low level framework. It has similarities with CommonJS (like goog.require, but differs as it has its own goog.exportSymbol & goog.exportProperty rather than module.exports). However, it does not completely abstract away html/css!
Is it good practice not to use much javascript/jquery? Should we avoid it as much as possible (for good accessibility)?
When is it OK to use JavaScript and when is it not in web design and development? In what scenarios and with what conditions?
Update:
I'm asking regarding public websites.
I have to respectfully disagree with the posters that say that you shouldn't use JavaScript, or use it sparingly, or have it degrade gracefully.
The reason is that the vast majority of people nowadays has JavaScript enabled and appreciates the desktop-like experience it can provide from a website. Really, who doesn't have JavaScript enabled? People act as if this is a statistically significant group. It is not.
Not using JavaScript is a little bit like nitpicking about variable sizes (oh, I can use a 16-bit integer here instead of 32-bit to save some memory). Unless you are doing some monster project for hundreds of thousands of people, where the ROI of the time you spend on making your website degrade gracefully is actually positive, you should use JavaScript as freely as you like. The two people that can't access it because they disabled it are paranoid and probably not the kind of people you want as customers anyways.
Just my 2 cents.
+1 to everything Mr. Expert said.
One more thing to add: it is not good for accessibility to have critical functions of your website rely on JavaScript. If JS is disabled in the user's browser, they should still be able to submit all forms, click all buttons, et cetera. Your website must degrade gracefully in the absence of JavaScript.
One note for forms:
Where possible, use the Hijax approach to submitting forms. Make them work using traditional page refreshes, and then use JavaScript to "hijack" the form submission and do it with AJAX instead. If the client has AJAX disabled, the forms will still work fine.
Before I say anything, let me make it clear that all of this is relative - its all about YOUR TARGET AUDIENCE. The answer can be on opposite ends of the spectrum if majority of your target audience is disabled people in Africa and my target audience is gamers in South Korea.
First, look at the ratio of JS enabled vs JS disabled in your target audience. For an average website, it is 100:1.
Second, consider bandwidth. jQuery minified and gzipped is 24K. But do all browsers work properly with gzipped contents? Choose the right UI framework or choose whether to use one at all, depending on your target audience's bandwidth. If your target audience is young people with heavy-usage broadband plans, they won't complain if the framework is megabytes in size. But when your website targets remote villages in some country for a relief effort or educational program or something then avoid such frameworks - they can barely get access to the Internet.
Third, for accessibility, two things are important:
Anyone should be able to see/hear/know the contents in your website.
Anyone should be able to perform all important functions in your website.
Once you take care of these using the minimum denominator technologies for YOUR target audience, you can always use javascript to pretty up things and enhance existing basic functions (auto complete, AJAX submit, etc...)
To sum it up, gracefully degrade.
Accessibility aside, I don't agree that we should gracefully degrade in the case where someone has JS disabled!
For desktops with browsers, saying that When people don't have javascript enabled, your website should degrade gracefully is like saying Your game engine should gracefully degrade to DirectX 6 because some people use Windows 95.. Doesn't make sense anymore. Note the word anymore. It used to make sense when JavaScript was only there on 50% of browsers and it was an emerging technology.
Anyone have any good reason why my 3D game should be able to degrade gracefully and use DirectX 6? Its moot. What DOES make sense is, my game uses DirectX 11 on Windows 7 but degrades gracefully and uses DX10 in Vista or even DX9 in XP.
Come on.. look at some stats. JS enabled to Disable ratio is like 100:1
Again the whole thing changes if 80% of your audience uses some upcoming web browser in a mobile device with shaky JS implementation to see your website.
If majority of your target audience/device has JS enabled, use it well. If they don't have, then don't. You just have to give them what they can use and see.
There will always be a minority, but if there is a pre-requisite to see a website and it is fairly widespread, they should have it installed/enabled or else its too bad for them. You certainly don't want paranoids in your target audience.
End of the day, only you will have the information that will help you decide how much you should use JavaScript. It is always dictated by your target audience and their devices.
If you are developing a simple website, then you should only use JavaScript to enhance the user experience, and it should degrade gracefully for those that do not have it enabled. If your website is content-centric, then that's how you should treat it: content first, JavaScript-based bells and whistles second. There should not be a single piece of required functionality that does not work without JavaScript enabled.
However, if you are making a web application, then go nuts with it. Web apps are supposed to use JavaScript, so it doesn't make sense to cater to people who have it disabled; if they really want to use your produce, they will enable JavaScript (or use a difference device). It's not worth all the trouble making it work without JavaScript enabled. That's like arguing that you should not give your video game good graphics because lower-end computers will not be able to run it: the people who really want to play your video game will upgrade their machine.
mhr's answer, "Always, as long as it degrades gracefully", is a good baseline. I would add that reasonable exceptions can be made where Javascript provides application functionality (your site is a "web app" rather than purely informational) that has no server-side equivalent. So for example, "graceful degradation" as a rule should not prevent you from building a web-based drawing tool (which would be, at best, unusably onerous if it degraded gracefully to forms and server-side functionality). It should, however, prevent you from requiring Javascript to access any content which that drawing tool publishes to an audience other than the content creator (because the content creator, self-evidently, has already accepted that Javascript is required for their usage of the site).
With all my respect to Mr J. Nielsen: Conservativism in design can be really senseless in terms of evolution an progress. When flash first appeared (with the first versions of actionscript, really take-away programming) a lot of noisy-glossy over animated interfaces raised, most of them almost impossible to operate in terms of usability. But the fact is that, form all those futuristic experiments, some qualitative improvements have arisen in terms of UI.
With javascript something similar happened: what was a merely widget is becoming more and more popular even transcending the presentation layer to handle some business logic: the RIA (Rich Internet Applications) are gradually relying on javascript for the user experience.
To use or not to use javascript?
I think every tool oriented to improve usability and interaction is welcome in a brand new world that evolves continuously and that is way too far to have a sharpen shape, direction or just a simple plan underneath.
What others are saying here is completely true: it is not worth thinking of the one or two that still have javascript disabled, as game producers don't care too much if your computer stinks and they keep pulling the limits of graphics. Thanks to this, we are no longer playing PACMAN (only if Google wants) and we can enjoy Assassins Creed.
NASA is a great example of how not to use JavaScript in a public website - they appear to be using JS to serve browser specific style sheets resulting in an unstyled mess with JS disabled.
The primary use of JavaScript is to write functions that are embedded in or included from HTML pages and interact with the Document Object Model (DOM) of the page. Some simple examples of this usage are:
Opening or popping up a new window with programmatic control over the size, position, and attributes of the new window.
Validation of web form input values to make sure that they will be accepted before they are submitted to the server.
Changing images as the mouse cursor moves over them: This effect is often used to draw the user's attention to important links displayed as graphical elements.
Because JavaScript code can run locally in a user's browser (rather than on a remote server) it can respond to user actions quickly, making an application feel more responsive.
On a public website it's ok to use JavaScript as long as the information that your site contains is still available and usability is still good for people without JS.
If you're in a more controlled environment like a companies intranet or something, you can maybe rely a lot more on JavaScript.
Also if your site is more an application than a document and it's functionality is just not possible without JS, you can of course use it.
You can also just accept the fact that some people will have problems using your site but rely heavily on JS anyway. That's your choice.
With javascript we can have a client / server relationship with users, in the sense that we can use their cpu power to build the page and free some resources from our servers. we deliver the code and data and their browsers put them together and it is as it should be. :)
Sincerely
Babak
well i am not agree with your point that not to use java-script and jquery regularly.
now a day browser are compatible with javascript.And if you have to develope a website in which validation is required u have to prefer javascript(for client side validation).
Your site should degrade gracefully, if only for one reason: NoScript. That Firefox extension depends on whitelisting to allow sites to run Javascript. That implies that sites that I've never visited before will not be allowed to run Javascript. It's a good way to prevent a lot of phishing attacks and cross site scripting (XSS) attacks.
Sites have to earn my trust first. Yes, Ebay and Amazon may heavily depend on Javascript, but a site like www.buyviagracheap.com may not.
And if, with Javascript disabled, you have nothing to show for, I'll press "back" quickly before you can say "but...", and never come back.
If, however, I like what I see, I may enable Javascript for your site and improve my experience. So there's no need to provide full alternative functionality with Javascript disabled.
I'm creating a blog, but I need box-shadows for my boxes, so I'm asking the following.
Is it good to add shadows via a)images/css or b)javascript?
I've heard that lot of people don't have javascript enabled while browsing, so is there this a problem? It would be easier and simpler to create these shadows with javascript than adding a million divs and positioning them.
EDIT: I found this page: http://www.w3schools.com/browsers/browsers_stats.asp and it says that almoset every user has js enabled.
You could use JavaScript for your layout, but the general principal that you should keep in mind is that your HTML should be semantic: the elements on the page should have a meaning; it should project a structure that goes beyond the design of the page (although that structure can certainly be used as an indcator for the design aspects as well).
When this principal is applied, using JavaScript can help with providing the style you wish to project given the semantic meaning of the page.
Also, you should check your server logs (your hosting provider should have some sort of analytics tool/report available) which should tell you what browsers and versions are being used to visit your site. With that information, you can get a good feel for the people that you are currently reaching.
If you are using some sort of analytics package (e.g. Google Analytics) then you can possibly see the delta between two periods of time for the new visitors to your site as well, and try to gauge the capability of the browsers that new users will be using when they visit your site.
A few things to consider when using JavaScript to manipulate the DOM on the front end:
If you are using JavaScript to manipulate a good deal of the content, it's going to be a client-side process, and that can slow down the rendering of your page. You might want to consider a theme/template for your blog/cms which gives you the styling that you want and is rendered through CSS on the server-side.
Search engines do not execute your JavaScript. Because of this, you want to avoid manipulating the indexable content at all costs. You want your content to be embedded in the HTML as it is sent from the server. Using AJAX or other JavaScript to manipulate certain things is fine, but when it comes to your content, unless you are stylizing it, do not use JavaScript to manipulate it
Use CSS box-shadow for nice, up-to-date browsers: http://css-tricks.com/snippets/css/css-box-shadow/ (requires no extra markup)
And for most everyone else, serve up your js solution.
You should do it the easiest way for you and allow the page to degrade gracefully for those without JS (If you think you need to consider them, as today, I don't see any point in building none JS sites or building sites for no-js users).
I have started using ajax/jQuery in our websites / application. There are many plugins that support degrading the javascript to browsers that dont have javascript enabled and techniques to support this. What are peoples thoughts on javascript support, we build applications rather than just websites and are looking to just support javascript enabled browsers as a pre-requisite assuming that most people or companies have javascript enabled.
Do you find most people have javascript? do you monitor the percentage of javascript/non-javascript browsers (I guess this can be done with website stats) and what are the numbers regarding this?
Whether you should be worried about this really depends on what sort of website you are creating. For instance, if you're creating a rich javascript app, you have to ask yourself if it's worth your time & effort to worry about javascript disabled browsers, as these users are probably not too concerned with using rich user interfaces anyway. Also do you have time to put in the extra work for these browsers as there will be little extra traffic and profit gained (if it's profit making website).
Also note that if javascript is disabled in these user's browsers, there will be much on the web these people cannot use. So in all likelihood they're not heavy users.
According to these metrics, the following percentages of users have JavaScript disabled:
EU: 1.4%
US: 3.05%
But the numbers are from 2007, so they are rather old. I would think the percentages are a bit smaller by now, but who knows?
I know this is a very old thread, but I thought I'd post this for reference:
According to this website, only 0.4% to 2.4% of users had JS turned off. The first test they ran was with about 13,500 users, which is admittedly small for the interwebs, but it's still quite a large amount of people. This data is from 2009
I really feel quite strongly that a well designed web site should remain functional with or without JavaScript switched on. JavaScript, in most cases, is there to enhance existing functionality.
This can usually be achieved by following a few simple rules.
Use unobtrusive JavaScript, avoid in-line (certainly) and in-page JavaScript whenever possible.
Anchors should always link to somewhere, not to # or to JavaScript. If you can't get around it, the link should be created dynamically.
Use forms correctly. A button should always be wrapped in form tags, this way the your functionality can always degrade to the server.
I believe that following these rules makes for a more robust site that is more accessible across multiple platforms. Not to mention the benefits to search engine optimisation, if you rely on JavaScript, the search engine will only see half your site.
I prefer the idea of progressively enhancing rather than planning for degradation. I'm absolutely not developing for the minority that intentionally sabotage their Internet experience by switching JavaScript off. A site built for progressive enhancement will work better on mobile platforms, screen readers and search engines.
Rich
As a whole, I think you can expect any browser that supports CSS will have JavaScript enabled.
However, it's not always a question of JavaScript being enabled/disabled on the browser entirely. Most of my friends/coworkers use NoScript to only allow JavaScript on specific sites.
It depends on what you are doing.
Is it a website or web application?
A website can be done with just static html and, if needed something a little more complex, a little bit of server side programming.
A web application, today, is all about javascript.
So if your visitors have js disabled, they are likely not interested in your application nor any other. So why bother with them?
Just concentrate in the other 98%, where your potential customers/audience is.
It deppends on the size,
Big applications like Gmail often have 'basic html' versions to support old and secured browsers. If you code your ajax with this in mind, you might be able to reuse most of the code.
Medium sized applications, especially if the user uses them regular, will probably not find it worthwhile to support the few percentages.
Small sites / sites that mostly uses basic html navigation, should try to do without javascript. Most of the time, modern css tricks will do better, faster and make more sense codewise.