As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would appreciate your opinions. I have been put in charge to redevelop a major site that does quite a bit of traffic. As of the past few months, I have been using Backbone.js to develop applications. I have been researching the last couple of weeks on whether Backbone would be a good fit for the redevelopment of the new site.
My initial concern was SEO. Found a great post here that talks about progressive enhancement and a bunch of stackoverflow questions that have helped to. I can't seem to shake the feeling that building a static site and enhancing it with Backbone is quite a feat and will take much more time.
Now my question is, have we not passed the stage where we have to build sites that have to work with javascript disabled? Is it essential that our site is still functional for screen-readers etc?
My idea was to serve the relevant meta seo information from the server into my main app.html file so search engines will still be able to crawl the different urls. The Backbone app will be launched from whatever url you visit that is relevant to the app.
I have just visited the new hulu.com, and cant seem to come up with a reason as to why not re-develop the website into a Backbone application. Most if not all websites I have visited, will not function without js. Go to hulu.com with js disabled and you will be able to see what I mean. So in closing is it safe to build a website that will not function without js and will the above suffice for SEO?
Thank you
I think there will be a lot of opinions on this. Here's mine.
As a default mind setting I always find backward-compatibility and graceful fallback important. I normally believe a site should be able to fulfill it's main purpose: delivering content (content sells).
However.. what if the purpose aka content is delivering some kind of functionality, like a online calculator or drawing application.. Then the user would already need and expect things like javascript to be enabled. In those cases I'll happily make design/layout things easer on me, using javascript. Think of a site like jsfiddle: who would care if this site didn't display it's ui properly because javascript was disabled.. Nobody.
As to SEO: I think there are a lot things that influence this. If you sell apples and you own the domain apples.com, your pretty much set anyway. Again, content sells, that is how most engines try to index.
Apart from that, in this (horrible) day and internet age, the most popular search-engines will both filter and rank the search-results to the user.. so if one wants to optimize a site for the search engine.. then for who's personal bubble (search results) do you try to optimize?!?.
I have more faith in something that was semantically coded, maintainable and has a pretty stable foreseeable future (instead of having to rebuild the same thing over and over again, every 6 months or so). Simpler put: make the core/base 'simple' enough to 'always' be rendered in a useful way and then add the spice using javascript and css-edge-technology to flavor the content.
Have you looked into node.js at all? Since your porting the view rendering to javascript anyways. It would be a little friendlier to have more components speaking the same language. Plus the asynchronous processing model releases a lot of server stress that threaded processes usually cause. Threaded processes spend a lot of time (and power) waiting to execute. But in javascript, folks usually set up callback methods. So instead of waiting for the previous process to finish, node just leaves behind a callback method to be executed when needed, meanwhile the rest of the application is still going full speed ahead.
node is really light too. You can use it along side other server side technologies and it wont take up much space. It has some pretty powerful features, but, personally, I find it best for view rendering (it's javascript after all). It also makes setting up servers and routing reeeaally easy. So setting up the stuff you mention in your 4th paragraph would be a sinch.
Anyways, that's my 2 cents.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
There's an awful lot on the web these days about how important it is to minify your JavaScript. Speed is all that matters.
But doesn't minification work against the openness of Open Source?
One of the great things about JS (as opposed to flash and the back-end) is that the source code is right there, available to be viewed by other developers who come along and think "Hey, that looks good, I wonder how they did that". The JS source code is available for everyone to see, and so developers can learn from it, adapt it, and use similar JS on their own projects.
Minifying JS makes it unreadable. It stops the external developer from being able to read the code, and so cancels out horizontal sharing and learning.
Obviously there will be some who wish to minify their JS for the express purpose of attempting to hold on to their intellectual property. It's always a shame when people undermine the creativity of the open-source community, but it's somewhat understandable, and certainly not going to stop.
But for the rest of us developers - the people who use open-source every day of our lives - JS minification gets in our way. It makes us unable to take advantage of the openness of the web. It closes down the possibility of creative sharing.
I'm all about some things being minified - libraries, plugins, etc (and maybe when serving JS to mobile). But for the custom-built code that makes your individual website individual, minifying your code is really not that necessary. It may save a few ms of download time, but keeping it open won't change that much. Most of the sites on the web probably have less than 20KB of custom JS code, and the benefit of minifying that really is minimal. Do a few ms really compare with the benefit of keeping JS code open, readable and available for others?
For sites with more JS, maybe we could start to develop an open-source-based standard, so that developers can type in a slightly different URL in order to be served the unminified code. If the minified code is at domain.com/script.min.js, let's make the unminified always available at domain.com/script.js or /script.full.js. Or are there other suggestions?
I can't really find anything else on the web talking about this issue. Everything is on the other side - pushing minification. And that alarms me. It makes me think that, as developers, we've allowed ourselves to sink into an unquestioned ideology of speed, regardless of other factors. And probably, because of the nature of ideology, some of you reading this will immediately want to dismiss it and argue against it. But think just a little bit longer - is the tiny speed benefit really worth the loss of open-source creativity? I don't believe it is.
So I guess my question is, where's the debate about open-source JavaScripting?
I'm pretty sure most — if not all — open source JavaScript libraries that offer minified versions also offer the original sources for developers to work on. It's just like how open source programs that distribute compiled binaries for general use also distribute their original sources to the public.
If you're referring to custom scripts made on a per-project basis specifically for a certain project, those scripts are not open source by default unless the author specifically cites/includes a FOSS license notice. To that end, I'm not obliged to provide an unminified version of my custom code unless I intend to distribute it freely and license it as such.
If the javascript is meant to be open source then you will also be able to find the un-minified version. For example, jQuery:
http://docs.jquery.com/Downloading_jQuery
There are both "minified" and "uncompressed" files for download.
If you find a javascript file which claims to be open source and does not have the uncompressed file available, then a mistake has been made.
Because there's no debate; I haven't seen many (any?) FOSS JS libs that don't have a non-minified version.
Even if there was, FOSS doesn't mean readable--even non-minified code can be completely illegible.
One of the great things about JS (as opposed to flash and the
back-end) is that the source code is right there, available to be
viewed by other developers who come along and think "Hey, that looks
good, I wonder how they did that".
I don't think we really want to encourage the practice of learning Javascript from the source of websites stumbled upon randomly. If you want to learn Javascript, it's much better to learn from an actual open source project that's been documented, tested and written with care.
99% of the time if I don't open-source a piece of JS, it's not because of intellectual property concerns. It's because it's a quick hack - not suitable for community consumption
Most of the sites on the web probably have less than 20KB of custom JS
code, and the benefit of minifying that really is minimal.
Whether or not the saving is 2kb (which still makes a difference, incidentally) or 2mb, minification is a best practice, and should be instilled in developers from the get-go.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have seen a web app that generate most of a page's markup by javascript+ jquery. The server only generate a web page with just 1 DIV . The rest are done with create on client side via javascript+jquery+AJAX .
What are the pros and cons of this javascript centric approach ?
Pros:
You get a lot of flexibility when your entire front-end is in javascript. Everything is generated dynamically and it's easier to load data on demand. It also makes it easier to bind elements to data, which allows them to update automatically as things change on the server (without requiring the user to reload their browser!). Check out Backbone.js or Knockout.js for interesting approaches to building heavy javascript apps.
Going this route also allows you to keep your server very light weight. Typically, the server just has to implement a simple RESTful/JSON interface. In practice, the frontend is a single static file and it makes calls to your interface. Since you're doing these calls asynchronously while the user is on the site, it can feel much faster and more like a native app (i.e. GMail)
Another nice perk is that having the client side do more work can often decrease the load on your server. The client won't even notice the extra work, since it happens so fast, but your server might appreciate the savings. You'll also potentially use less bandwidth if you're smart about your server calls.
Cons:
Some people have javascript disabled (although in practice it's a fraction of a percent of users). Also, browser cross-compatibility can be more difficult in some edge cases (but jQuery makes this much more tolerable). The biggest con is that many web crawlers won't crawl anything on your site because crawlers generally don't execute javascript. They just parse html (Google might be an exception here?).
In my experience with building web apps, any public facing content (i.e. marketing material) should be static content so that web crawlers see it. Once the user logs into the app, I like everything to be 100% client-side with RESTful calls to my server.
Always aim to separate concerns:
Information in markup
Style in CSS
Behavior in Javascript
If you start doing everything in Javascript alone, you break that model. And the model's worked pretty well for the web so far.
That being said, do use javascript for progressive enhancement of a site. E.g. if you can display something via ajax instead a page reload, then go ahead, but a normal page request should also still work.
Check out github's repository browser for a great example of progressive enhancement. If you're using a brower that supports it, it'll load pages via ajax, and change the url in the address bar to match. Otherwise, it'll do what it's always done, and simply go to the page with a normal link. So there's javascript in there, and does some cool tricks, but everything works without it.
Con: very large javascript file
Con: if javascript turned off your site does not work
Con: harder to style
Con: large javascript file returned to client with potentially more
code than is needed
Con: possibly difficult to debug
What if your interface returns large lists, do you need to return that also and loop through that in JS and build your controls and add them?
Well, you're not exactly being quite clear when you say "generated from javascript with jquery+ajax". That could mean that flat HTML pages are just being loaded in, as opposed to requiring a browser refresh. There's no right or wrong way to structure dynamic versus static HTML; everything has to be taken in context.
jquerymobile uses this technique quite extensively.
The server should do the heavily lifting because that's what it is there for. The involvement of the client should me minimal. Client side development should focus on enhancing the UX and making sure things work nicely on many browsers. It should not be about tasks like restructuring the DOM to be a certain way, sorting and filtering through data, and so on - unless there is a compelling reason.
So offloading too much of the presentation logic on the client is probably a bad idea, in my humble opinion.
You are contrasting
Server produces data (usually JSON) -> Client-side Java Script creates HTML
Server produces data, server formats HTML -> Client renders HTML
An application can use some combination of those techniques, the former makes it easy to give dynamically updating pages with a rich user experience. You will notice that the former also offloads more work to the client (I assume that JSON is more terse than the resulting HTML) and hence in the long-term once the JavaScript is downloaded and cached the network bandwidth is reduced.
The JavaScript-centric approach is more complex and typically needs more effort to write.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am designing a one page browser based web application.
JQuery is already being used in my application. I am currently planning to use KnockoutJS for data-binding and UI management. However I have used Backbone.js in past, and I have been quite impressed with the routing facilities provided by the controller layer.
I have also looked into some JQuery-based solution like pathjs for client side routing.
It would be great if someone could offer suggestions and guidelines for choosing a proper routing system.
I am not willing to use Backbone.js instead of KnockoutJS because of the excellent data-binding facilities of KnockoutJS.
After going through a bit of exploration I have found the solution.
#Eisenhauer Backbone's routing facilities are awesome, but what if I am not using Backbone.
As I outlined in my question, I am already using KnockoutJS that provides me a client side MVVM model and so its not really a good idea to put an additional MVC implementation in the same page.
For people looking for a standalone routing solution, pathjs is a simple and elegant solution.
A more flexible, powerful and standalone routing solution is Crossroads.js available at http://millermedeiros.github.com/crossroads.js/.
It is very nicely documented and really powerful,so can be adapted to any set of requirements.
You could use the History API rather than a hashbang approach?
It allows you to manipulate the URL displayed to the user.
It means that back / forward work sensibly.
Bookmarking the page works sensibly.
It's better in terms of performance, because if the user refreshes a page (or hits a link to the page from an external source) the correct content is loaded first time rather than having to load a blank page and then grab the correct content via AJAX.
The downside is that older browsers will not support it. You could fall back on a hashbang approach (if you really have to). I don't know of any existing frameworks that do this though. I would prefer to fall back on not dynamically loading content (i.e. full page reloads when the user clicks a link). The history API will become more and more widely supported, so this "problem" will reduce over time.
Here's a working example with some documentation. From the address bar, it looks like pages are loading "old school" (full page refresh) but if you take a look at the console (Firebug, Chrome dev tools), you can see that the content is being grabbed via an AJAX request.
Mozilla has some docs about it.
Also there is excellent Director
Crossroads.js seems to be one of the best around. One major advantage of it being, it doesn't rely on window.location for routing. It's lightweight as it sticks to do just routing and routing alone.
Others you may want to try: finch.js,
davisjs (based on pushState so that you can use existing links as a fallback if JS fails)
Appending an update: March 30 2015 -
I had moved to AngularJS late last year. Hands-down the best switch form JQ, has a lot of modules like routing in-built.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I'm fairly new to this whole web-development thing (2 weeks maybe, my 1st scraping of code exists here, I quite like it) and I ended up learning to use Adobe's Flash Builder 4, which I have come to quite like (although Action Script annoys me at times).
Recently however I've been reading a lot about "the future" of web development, RIAs, web 2.0 etc, and it appears the whole Flash/Flex/ActionScript frame work's main competition will be the HTML/CSS/JS stack (or "HTML 5").
So obviously I don't want to take the time to learn a language (Flash/Flex/AS3) that will end up dead in a couple of years and end up having to learn another one (HTML/CSS/JS), when I could just move over now.
My main interests are fairly information rich (database orientated) web sites, with high levels of user interactivity for customisation, uploading, etc. I like the whole mobile web aspect, and would like to have the capacity to also develop for that platform, as well as mobile apps etc. I love the whole "live" aspect (like the tour de flex light up map that shows user activity), not particularly bothered by uber complex animation and obviously want things to be responsive and user friendly.
So yea, any input on this would be much appreciated, I'd just like some advice for overall direction for my personal learning and development.
Thanks!!
You're making some basic mistakes in the question. The HTML/CSS/JS combination is different from HTML 5, That combination works just fine with current implementations (ignoring some of the annoyances of IE for the moment.) HTML 5 is a new extended definition of HTML with a number of new features like local storage.
HTML 5 is also not completely settled, nor completely supported.
You should learn HTML and CSS to start with; in general, you still need a web page in which to embed your Flash stuff. You should get some basic knowledge of Javascript for much the same reason.
Conveniently, the Javascript will carry over to Actionscript, which is a variant of the same ECMAscript standard.
Flash isn't going anywhere for a long time, and given the glacial pace that the HTML5 committee is working at, the HTML 5 spec won't be fully standardised for a while yet either.
Plus before all these lovely HTML5 web apps can become commonplace, the world's windows users will need to have a better browser than internet explorer 8. Given that 10-20% of web users are still stuck on IE6, i don't think we'll be seeing html5 becoming dominant for quite a few years. Of course then by that time we'll be seeing HTML6 and the slow painful process of getting the world to upgrade will start again.
Personally i don't do flash, because for what i do i really don't need it, but flash is a really useful tool outside of web development too. Lot's of triple A Games have flash built menu's and user interfaces for instance.
But really, become good at either/both technology, and you'll probably not be short of work
Learning a language like Actionscript can never be a waste of time , the mindset you will develop from it will enable you to understand the concepts of programming and it'll be easier for you to move to other languages if/when you so desire. Learning HTML & CSS is essential if you plan to develop for the web but it will not bring you the same type of knowledge, as it uses a very different logic. If you like the idea of developing web applications, one day you may want to develop desktop applications, HTML won't be of much use then, whilst the programming knowledge acquired with AS3 will not be lost.
Is this just for the fun of learning, or do you have any specific tasks to accomplish? I like to use the correct tool for the job. If you don't have a specific job to accomplish, or any constraints to work under, I would just pick the most marketable skill and go with that. Unfortunately, I'm not exactly sure which is the most marketable skill.
My recommendation would be to check out some JSON type stuff in JavaScript. That seems to be a pretty stable (might I even say fad-resistant) AJAX evolution which is pretty wide spread and likely to stick around for a while. If you focus on the high level theoretical concepts, the specific comings and goings of implementations won't be as important (in my opinion).
I think learning AJAX (using JSON rather than XML) is a good way to go so you learn about implementing asynchronous information rich sites. If you have to redraw the site entire site when you pull information, you're doing something wrong. The AJAX concepts will come in handy regardless of your platform.
Good luck!
-Brian J. Stinar-
Don't bother with flash.
Yes, it's pretty and powerful and fairly ubiquitous. It's also on its way out the door, as you observed in your question.
Let's compare Flash and its newly-arrived competitor, the HTML5 canvas element.
Flash is only supported by Adobe; if you want quality development tools or resources you'll have to buy from them (for the most part).
HTML5 canvas doesn't need proprietary development tools. HTML5 canvas is supported by every major browser vendor -- Mozilla, Apple, Google, Microsoft. All vendors will provide documentation and competition for each other, which should result in a more refined product.
When OpenGL support (direct gfx card access) was in discussion for HTML5 Canvas, guess who was the only holdout? Adobe, of course. Everyone else wanted hardware graphics support for canvas.
In other words it's Adobe against everyone else here, and Adobe's not going to win. They might keep the status quo for a while, but eventually they'll lose their foothold and canvas & co will take over.
tl;dr: No use learning the dying proprietary technology when you can learn the modern open technology that's going to replace it.
HTML5 is still very unstable, so you shouldn't try it.
For me, HTML5 is great, but some business haven't moved off of IE6, given its current state. Flash, while useful, can be very very tedious at times and other times it doesn't even work on some computers or makes some computers truly a pain in the "insert word here".
It's better to start with CSS and HTML4. Get the basics, then start going for more.
By then, you'll know what to want.
Personally I think all the answers here are overcomplicating things. Here's my take:
Use whichever technology excites you, and is best for what you want to build right now.
If the app you want to build right now feels perfect for Flex, use Flex. If something about HTML5 has caught your fancy and won't let go, dive into it. You can always change technologies in a year or three, and You'll be taking everything you've learned about design and architecture and usability with you - learning a new scripting language and some new tools won't be that bad. The only way you can make the "wrong" choice here is if you, for whatever reason, pick a technology that you wind up not enjoying enough to get anything built.
The reason I feel this is the best way is, nobody here can tell you anything useful about what technologies will or won't be around in a few years' time. Adobe could go bankrupt; Steve Jobs could die; Google could get broken up in an antitrust suit. Hell, Flash could be on the iPhone next year for all we know - or HTML6 could adopt a new, strongly-typed JITable programming language. Or a hundred other things could happen to render your (and our) predictions moot.
I mean, personally I expect that both Flash and HTML5/6/7 will be vibrant and flourishing in five or ten years - because they both have successful organizations behind them investing in their futures, and because I've never heard a whit of a meaningful argument why the success of one should require the failure of the other. But that's just a guess, and my guess is no better than yours. Focus on getting good stuff made now, and the technology road map of the future will come when it comes.
In my opinion – everything is worth learning, especially when it comes to HTML/CSS/JS/Flash, which are each completely different systems/skill pools tailored to entry-level developers.
HTML is tagged markup, and very important because it outlines XML usage. CSS is writing visual formatting rules. JavaScript is a scripted language, and a great way to get your feet wet with simple programming logic. And Flash is a great system in which to get into object-oriented programming within a compiled language.
As you keep venturing out, you'll find that a lot of technologies are really just different flavors of the same ice cream. While different languages have their own nuances, there are fundamental similarities between –say– most compiled languages. I came from Flash and got into iPhone development... while Objective-C is a way bigger and uglier system to dive into, I still generally knew my ass from my elbow while building my first app after several years experience with AS3. The same goes for .NET and Java. Also, I would second the notion that Flash is not dead, despite loosing traction in the wake of the iPocalypse. Whether it dies in a few years or not, it doesn't make AS3 any the less valuable to have learned in addition to HTML/CSS/JavaScript.
This question already has answers here:
Do web sites really need to cater for browsers that don't have Javascript enabled? [closed]
(20 answers)
Closed 9 years ago.
We're developing a web application that is going to be used by external clients on the internet. The browsers we're required to support are IE7+ and FF3+. One of our requirements is that we use AJAX wherever possible. Given this requirement I feel that we shouldn't have to cater for users without javascript enabled, however others in the team disagree.
My question is, if, in this day and age, we should be required to cater for users that don't have javascript enabled?
Coming back more than 10 years later, it's worth noting my first two bullet points have faded to insignificance, and the situation has improved marginally for the third (accessible browsers do better) and fourth (Google runs more js) as well.
There are a lot more users on the public internet who may have trouble with javascript than you might think:
Mobile browsers (smartphones) often have very poor or buggy javascript implementations. These will often show up in statistics on the side of those that do support javascript, even though they in effect don't. This is getting better, but there are still lots of people stuck with old or slow android phones with very old versions of Chrome or bad webkit clones.
Things like NoScript are becoming more popular, so you should at least have a nice initial page for those users.
If your customer is in any way part of the U.S. Goverment, you are legally required to support screen readers, which typically don't do javascript, or don't do it well.
Search engines will, at best, only run a limited set of your javascript. You want to work well enough without javascript to allow them to still index your site.
Of course, you need to know your audience. You might be doing work for a corporate intranet where you know that everyone has javascript (though even here I'd argue there's a growing trend where these sites are made available to teleworkers with unknown/unrestricted browsers). Or you might be building an app for the blind community where no one has it. In the case of the public internet, you can typically figure about 95% of your users will support it in some fashion (source cited by someone else in one of the links below). That number sounds pretty high, but it can be misleading; turn it around, and if you don't support javascript you're turning away 1 visitor in 20.
See these:
https://stackoverflow.com/questions/121108/how-many-people-disable-javascript
https://stackoverflow.com/questions/822872/do-web-sites-really-need-to-cater-for-browsers-that-dont-have-javascript-enabled>
You should weigh the options and ask yourself:
1) what percentage of users will have javascript turned off. (according to this site, only 5% of the world has it turned off or not available.)
2) will those users be willing to turn it on
3) of those that aren't willing to turn it on, or switch to another browser or device that has javascript enabled, is the lost revenue more than the effort to build a separate non-javascript version?
Instinctively, I say most times the answer is no, don't waste the time building two sites.
My question is, if, in this day and age, we should be required to cater for users that don't have javascript enabled?
Yes, definitely, if the AJAX functionality is core to the working of your site. If you don't, you are effectively denying users who don't have Javascript enabled access to your website, and although this is a rather small proportion (<5% I believe), it means that they won't be able to use your site at all, because the core functions are not available to them.
Of course if you're doing more trivial things with AJAX that just enhance the user experience but are not actually central to the core functionality of the site, then this probably isn't necessary.
Depends really.
I personally switch off JavaScript all the time because I don't trust lots of sites.
However, since you users have explicitly asked for your application, you can assume they will trust it and there is no point in doing extra work.
More, if you have that strong AJAX-affinity requirement, the question seems odd enough.
This is a bit like beating a dead horse, but I'll have a go at it, sure.
I think there could be two basic approaches to this:
1.
Using ajax (and, basically,
javascript) to enhance the experience
of the users, while making sure, that
all of the application's features
work without javascript.
When I am
following this principle, I develop the
interface in two phases - first
without considering javascript at all
(say, using a framework, that doesn't
know about javascript) and then
augment certain workflows by adding
ajax-y validation (don't like pure js
validation, sorry) and so on.
This means, if the user has javascript disabled, your app shall in no way break or become unusable for him.
2.
Using javascript to its fullest, "no javascript - no go" style. If javascript is not available, the user will not be able to use your application at all. It is important to note, that, in my opinion, there is no middle ground, - if you are trying to be in both worlds at once, you are doing too much extra work. Removing the constraints of supporting no-javascript users, obviously adds more opportunities to create a richer user experience. And it makes creating that experience much easier.
I think that depends on the type of web application you are going to build. For example in an e-commerce application the checkout process should propably work without java script because there are some people who deactivate js for checking out (in our experience). In a web 2.0 application in my opinion it isn't necessary to support non-js browser experience.
Developing for both also complicates the development process and is more cost intensive. you have double your web test efforts (testing with and without js) and also think different in the planning phase.
I think it depends on the market segment you're aiming for, if you're going for a tech crowd -such as Stackoverflow.com, or perhaps slashdot- then you're probably fine in expecting users to have JS installed and active.
Other sites, with a medially tech-aware audience, may suffer from users knowing enough about JS-based exploits to have deactivated JS, but with not enough knowledge to enable Scriptblock (or other browser-equivalent).
The non-tech aware audience are probably with the tech-crowd, since they possibly just don't know how to disable JS -or why they may want to- regardless of the risk.
In short, you should cater to spiders without JavaScript enabled, but only to the degree necessary to index the data that you want to expose to the public. Your browser requirements of IE7+ and FF3+ exclude far more people than the total number of people who disable JavaScript. And of those who do disable it, the vast majority know how to enable it when necessary.
I asked myself the same question the other day and came up with the answer that in order to use my application one must have Javascript enabled. I also checked various Ajax powered sites. Even Stackoverflow.
But considering this fact I also believe that you do need to support some degree of prehistoric applications. The main idea is to not let application break when users don't have enabled Javascript. Application should still display relevant data, but its functionality would be limited.
To add to some of the old discussion on this page. Google is now searching JavaScript: http://www.i-programmer.info/news/81-web-general/4248-google-now-searches-javascript.html
This is an issue that I was thinking about just a few days ago. Here is some information
In Google Chrome there is no way (menu/option) inside the browser to turn off Javascript.
Many websites including those from leading names like Google, etc., will not work without Javascript.
According to stats over 95% of visitors have Javascript enabled now.
These stats made me think. Do I have to break my back writing a lot of background code and everything for users who have disabled Javascript?
My conclusion was this. Yes, I have to include Javascript support, but not at the cost of sanity. I.e. I can afford to give it a low priority.
So I am going to have support for non-javascript browsing, but I will build most of it after my site is deployed.