

Educate HN: AJAX doubt - swah

I really like the idea of making a rich web application using static pages + AJAX.<p>I don't understand how would I solve this though. In something like Django one would just render the variable in the template.<p>The problem: browser visits twitter.com/john - or twitter.com/user/john to makes things simpler.<p>We should then serve a static page - say user_profile.html, which displays the static part of the user profile page and loads Javascript that will load the dynamic, user-specific part using AJAX.<p>Now, how would one pass the username "john", from the URL to the javascript, so we can then make the AJAX calls like get_user_tweets("john") ?
======
mike-cardwell
You would parse document.location to obtain information from the address bar.
Eg:

document.location.pathname would contain "/user/john" if the url was
<http://twitter.com/user/john>

This isn't really a javascript help forum.

~~~
mike-cardwell
Also, good web design practice, (and law in some countries) dictates you
should make a site which doesn't rely on javascript, and only uses it to
enrich the experience.

~~~
kls
_good web design practice_

Who's good design practice? The world moves on, web apps are build with
JavaScript, people now respect JavaScript as a decent language that has it's
quarks and the DOM has been tamed by the toolkits. The best in the industry
are flocking to JavaScript based web application and abandoning the contorted
server side frameworks in droves. Why? because the programming model is
simple, the separation of concerns and disciplines are clean and the ability
to prototype rapidly on the front end is not bound by the rigor that the back
end requires.

~~~
mike-cardwell
Industry wide, commonly considered and accepted, best practice.

Make sure everything works without javascript, and then add as many bells and
whistles as you like with javascript afterwards.

~~~
kls
Most people make a business case for any feature that they implement or
technology that they use. Just because something is a recommended practice
does not mean it is a best practice.

When one looks at the numbers of older non-supporting browsers and people who
intentionally turn Javascript off. It does not make a compelling case to adopt
an older more costly development model that cannot support the superior
feature set of the new development model. Just as COBAL was once a recommended
practice it no longer is, the world moved on.

As for the 5% or less that still cannot execute Javascript for whatever
reason, study after study has highlighted that you spend an exponentially
larger volume of money to chase this market than you do on the 95% solution.
Money that for all intents and purposes would be better spent trying to
increase conversion in the 95% market or adding new revenue stream to provide
to the 95% market.

So when we talk about best practices we should be mindful of the technical
egos, as well as lack of any business grounding of some of the people that
make up "Best Practices" that believe their way is the only way and always
offset it with marketing 101.

JSP has best practices, ASP has best practices and PHP has best practices some
conflict with each other and none are weighed against what you are personally
trying to achieve. At one point in time in the industry unified programming
environments where the DB, the code and the execution platform where rolled up
into one technology where "Best Practice". The list of no longer in vouge best
practices stretches from hear to Siam.

Whenever best practice is seen it should serve as a red herrin that someone
may not be listening to opposing view points. People in the technical industry
following other people blindly is why we get so much group think and brain
dead design patterns from people who believe in the Highlander model of
development. JavaScript is standards compliant and that is all that should
matter, the rest is just working the numbers.

~~~
mike-cardwell
If you make a website that requires javascript to work. If you don't provide a
non-javascript alternative. You have made a website which isn't accessible,
and when you grow large enough, you will probably be sued.

~~~
kls
Come on now, [http://www.dojotoolkit.org/reference-
guide/dijit-a11y-statem...](http://www.dojotoolkit.org/reference-
guide/dijit-a11y-statement.html) . I am doing a project that is using
Javascript for a huge public tech company, who gets sued all the time for
accessibility for the specific reason that JavaScript can be used to increase
accessibility.

~~~
mike-cardwell
I fail to see how that's relevant. There's quite a marked difference between:

1.) Creating a website which uses JavaScript to increase accessibility

And:

2.) Creating a website which requires JavaScript in order to function

I only have a problem with number 2.

