I recently began as a web designer but spend more and more time learning front end web development. I enjoy Javascript and the work. I am very interested in creating web applications unfortunately I find that Javascript frameworks change so quickly. I began learning Angular 1.3 only to find the release of 2.0 to kill my interest. I also worry that learning frameworks will not help my skill as a developer only as a framework user. It makes me want to just develop with modular Vanilla.
What recommendations do you have for creating web applications with this problem in mind? I greatly appreciate your comments.
One of the best things you can learn as a developer is to ALWAYS find a solution before creating one.
Yes, vanilla Javascript surely has it's place, for as you progress as a developer, you too will want to write your own javascript.
I recently just got into MEAN stack development, and I can definitely say if I were to try to write all of this by hand, especially if your not an expert, would be a nightmare, if not impossible/impractical.
I understand the craving / desire, we all have it. We start to code and feel like wizards when we can conjure up this neat program we build all by ourselves. But we also have to realize there is a little bit of reasoning behind utilizing frameworks, just take this into perspective, taking MEAN stack as an example,
Right now, there are a team of developers working on MongoDB, a team of developers working on Angular, Express, NodeJS etc.
Each of these frameworks is being FOCUSED on and perfected, think about that for a second. These aren't things that are just thrown together, these are strong written frameworks, and when combined together, can make an awesome toolset.
Building your own library can also be a good idea, and I would encourage it, especially for CUSTOM solutions. This can be fun and creative.
However, as for making the strongest web framework you can have, it would take more work than whats practical. Utilizing the work of others is one of the most important things you can do as a developer! Good luck.
You could resort to Google Trends to figure out which technologies last and where the trend is going. A quick research points very much to the study of jQuery (even though AngularJS trend is more impressive):
http://www.google.com/trends/explore#q=AngularJS%2C%20%2Fm%2F0268gyp%2C%20%2Fm%2F02p97&cmpt=q&tz=
Going Vanilla is always a good idea in order to strengthen your understanding of the fundamentals - learning some popular frameworks is essential to work productively and find good projects!
Disclaimer & Long Winding Question Approaching
I know topics like this have been beaten to death here so suffice to say I'm not asking about which framework is better, I don't really care about opinions on the better framework. They all do pretty amazing things.
The Question
Given that I have an existing web application, made of mostly regular HTML+CSS (jQuery where needed), which is the optimal framework to integrate a few "rich" pages into typically a regular stream of HTML.
Reason
I am trying to bring our proven application into the realm of awesome desktop like UI but I want to do it one small piece, one screen at time. But for our users, support personel and especially me taking it slow is the only option.
Also, with our branding requirements having a framework that just takes over the viewport isn't an option, it has to play nice with other HTML on the screen.
Imagine the example being a rich user manager in an otherwise plain HTML+CSS environment.
Experience Thus Far
Dojo + Dijit
Pros: The new 1.5 widgets plus the claro theme is the cure for what ails us. Dojo seems to be able to use markup to create the UI which is very appealing and has a fair amount of widgets.
Cons: Holy bloated lib Batman! Dojo seems to be enormous and I have to learn a custom build system to get it to stop requesting 4,800 javascript files. This complex empire of Javascript makes me believe I won't be able to create much that isn't already there.
ExtJS
Pros: Amazing set of widgets, does everything we could possibly want. Seems quick, every version brings new improvements.
Cons: I'm not sure how to use this without the entire display being EXT. I'm still building a web site, so I would prefer something that could integrate into what we already have. Some pointers here would be great.
YUI
Pros: Well, it's Yahoo isn't it? AWS console is downright wicked. Plenty of support and a giant community.
Cons: Well, it's Yahoo isn't it? AWS console is the only wicked thing. Complex for someone who's used to jQuery.
Help Me
I am willing to accept experience, links to ways to solve problems I've outlined, new toolkits (even though I'm pretty sure I've seen most by now) or even just advice.
Regarding ExtJS, it's pretty easy to start it in an existing div with something like this:
Ext.onReady(function() {
App = new Ext.Panel({...})
App.render('div-id')
});
The App panel can then have it's own layout manager.
This might be useful if you're familiar with jQuery, but not yet familiar with YUI 3 syntax: http://www.jsrosettastone.com/
Each of the libs you listed is excellent. When embarking on a larger scale project, the quality of a lib's documentation, community, and commitment to support become more relevant.
With Dojo, keep in mind that outside of dojo base, it only ever loads what you tell it to. But yes, without a built layer, that means it could easily end up requesting 50 JS files at startup for a large application using a bunch of widgets.
There are several pages in the reference guide documenting the build script: http://www.dojotoolkit.org/reference-guide/build/index.html
Rebecca Murphey wrote a nice blog post outlining an example app and build profile that you might find illuminative: http://blog.rebeccamurphey.com/scaffolding-a-buildable-dojo-application
If you get stuck, there's likely to be people in the Dojo IRC channel that can help.
RE ExtJS: I'm not sure what your exact situation is, but keep in mind that if you're intending to use it in commercial non-open-source software, you need to pay for licenses: http://www.sencha.com/store/js/
I'm a little curious as to why you think the size / number of requests is specifically an issue with Dojo though. I haven't used the others, but I'd expect it to be somewhat of a potential concern with any of them.
Often I need to refer to code written in HTML/JavaScript/CSS, but it is a very awkward construction to constantly refer to the descriptive trio of 'HTML/JavaScript/CSS' code.
for example, Mozilla refers to its HTML/JavaScript/CSS JetPack code as 'a JetPack'.
Other than the defunct 'dHTML', what are some concise, generic and accurate terms I can use to collectively refer to applications written in HTML/JavaScript/CSS.
I'm going to have to say DHTML anyway. Why would you say it's "defunct"? It is the perfect answer to this question. See http://en.wikipedia.org/wiki/DHTML. DHTML means Dynamic HTML—which is exactly what the combination of HTML/JavaScript/CSS code is.
Unless you're dealing with someone who isn't impressed with terms that are less than a year or two old, or unless you aren't specifically talking about code, DHTML conveys exactly what you are talking about.
Web application is perhaps too loose of a term, but it's a start.
Let's break it down.
HTML is data, CSS is presentation, and JavaScript is code. These are web technologies.
These are usually brought together by a browser.
Something in a browser on the web is a website.
JavaScript suggests it is somewhat interactive, so it's not just a site, it's an application.
("Application" also suggests that it's more complex, like with a SQL backend or something, so you might sound even more talented. :)
I'm guessing that you had the term LAMP (Linux, Apache, MySQL, and PHP) in mind? To my knowledge there is no such abbreviation for HTML, CSS, and JavaScript. The easiest way to say it is to just say it.
Versus "Front end" – I think that term implies that you built something that customers used. "Web application" is nonspecific about who the users are, so it would apply to customer-facing applications as well as internal-use applications. The word "application" implies that it's not just a tool; there are users who are not the programmers. "Front end" is probably more impressive because a customer-facing application has to be nicer than an internal one.
If you are not using it in a browser, or it's not actually on the web, maybe just your intranet or an internally distributed application bundle, it's still an application developed with web technologies.
Given that the person you're trying to convey this message to knows you're talking about web-related stuff - Front-end or Front-end development has always worked for me.
"HTML5" is the answer I now believe to be correct to replace "HTML/JavaScript/CSS". Since I asked the question in January, HTML5 has gained a lot more recognition for its incredible capabilities and promise. "HTML5" also has significantly greater name recognition than 7 months ago, and clearly sets it apart from lesser HTML.
I think the reason there's no specific term is the same reason that dHTML fell into disrepute - all three scripts are so integral to frontend development that there ceases to be a need to refer to them specifically. If you code in HTML, you almost necessarily use CSS, and if you have any active content at all it will most probably be in JavaScript.
Frontend development is a bit vague, but something like HTML based frontend development should get your point across.
If you want to refer to an application - use Web Application.
And if you need to refer to some code - use simple JS (JavaScript) because most of your code (except for some ie css expressions if you use it) will be in JS, isn't it?
Web Suite
suite: a set of things belonging together, in particular.
thus you have:
Web Suite: the set of HTML/CSS/JavaScript, the basic technologies used to develop a web site or application.
example:
"I used the Web Suite to make a cool website to show off all my pictures of cats sitting in boxes."
"UX" (User Experience) or "Front-end Development."
Web Applications, and Web 2.0 are both big names. One name/acronym that I personally like to use is RIA, or Rich Internet Application. From the article:
Rich Internet Applications (RIAs) are
web applications that have most of the
characteristics of desktop
applications, typically delivered
either by way of a standards based web
browser, via a browser plug-in, or
independently via sandboxes or virtual
machines.1 Examples of RIA
frameworks include Ajax, Curl, GWT,
Adobe Flash/Adobe Flex/AIR,
Java/JavaFX,[2] Mozilla's XUL,
OpenLaszlo and Microsoft
Silverlight.[3]
Also, someone else mentioned "impressing the suits," which this title tends to do. After all, it's got "rich" right in the name ;)
Web code
I was just having to write "HTML/Javascript/CSS" in an email and thought, "Isn't there a better term for this?". Googling, I found this post. I'm going with "web code".
Some call it a JAM stack, which stands for Javascript, API and Markup. But I acknowledge that it's not as specific as LAMP or something like that.
https://en.wikipedia.org/wiki/Solution_stack
https://jamstack.org/
However uncool it might be, it is still DHTML to me.
They are standard web technologies for producing dynamic websites and web applications. The last thing we need is another vacuous moniker for something that is more than adequately described by DHTML.
An Alternative to this Source or Page Source.
The Context all depends but for me this seemed to be a good name. When I right-click and I see "view page source" it seems relevant. it contains all of this HTML/CSS/JS.
I like Web Application but my use case was page-specific, not app-wide.
I've been calling this the web stack (HTML, CSS, JavaScript). Exclude frameworks or other tools, just the base technologies of what the web is made.
I am going to start a new application which mainly consist NavigationPane, Grid, Toolbar. Layout should look like this demo page http://www.gwt-ext.com/demo/
I am quite confused which one to use in terms of writing less code, more performant, etc..
Could someone tell the pros and cons of all these technologies.
All the while I coded in javascript, so that way ExtJs seems to be the easy one for me to code. But I am curios to try GWT Ext, Is it true that it could do a lot just by writing few lines of java code.
For eg: To achieve the layout ( given in above gwt ext demo url), which one should I opt ExtJs or GWT Ext.
I read SmartGWT is relatively slower than GwtEXT. Does it have any advantage over GWT EXT. I am also looking for hibernate based data modules ( as my application is going to have many database calls). Anyone of SmartGWT or GWTExt has support for such modules. I came to know that smartgwt doesn't offer all of smartclient enterprise version functionalities, that we are allowed only a few of smartclient features. Will it be an issue?
Your response is highly appreciated.
The GWT-Ext main page now says
"GWT-Ext is no longer under active development and has been superseded by Smart GWT. Assistance will be provided to existing users of GWT-Ext looking to migrate to Smart GWT."
so why would anyone use it?
To write the least code, use SmartGWT Pro. It provides a wizard that allows you to just pick from a list of Hibernate entities you've created, and instantly you have the ability to perform all CRUD operations on that entity, no code required. Then you can add business logic.
The wizard:
http://www.smartclient.com/smartgwtee/showcase/#tools_hibernate_wizard
The link about is just screenshots, but there are several Hibernate samples in the showcase. See especially the Master-Detail Batch Load and Save sample.
As far as performance, real-world performance of most enterprise apps is dictated by how often the application has to contact the server. In this area SmartGWT has a large lead because of features like Adaptive Filtering (see the Featured area in the SmartGWT showcase).
Almost all reports we receive of SmartGWT being "slow" are due to having Firebug enabled. Disable Firebug and performance is fine, so normal end users will never perceive slowness.
About 6 months ago, we studied whether we would use ExtJS or GWT-Ext for an internal application. We wanted the back-end to be J2EE standard frameworks (struts, spring, hibernate for persistence, etc.). We ended up choosing ExtJS because it seemed to us that GWT was not stable enough (too many changes in the API that is still recent), and Ext-GWT was always lagging behind in development.
application which mainly consist NavigationPane, Grid, Toolbar.
Well, this tells us a lot about your app, doesn't it :)
I think it comes down to how good you are at either Java or JavaScript. They are quite a different languages you know :) But if you are well-versed at both but only used Ext JS, then picking up Ext GWT (or GWT Ext, if you meant that), shouldn't be such a great deal. And if that application you are planning is going to be as simple and small as your description of it, then it's probably a perfect opportunity to try out something new.
I use GWT-Ext and it is quite good especially if you don't mind tweaking things with JSNI to customize the already existing Ext widgets it is incredibly powerful. Unfortunately development is stagnant, so my future projects will probably be either in SmartGWT or Ext-GWT. SmartGWT is written by Sanjiv Jivan (same guy who wrote GWT-Ext) and it has most of the widgets we need. I must say most of the skins are quite dated except the Enterprise skin which looks good, but you can always roll your own skin.
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.