How to build a desktop like application interface using JavaScript?

JavaScript
101

There are a variety of situations where javascript is not available to a web browser.

[list][]Lack of support (Lynx, JAWS, crawlers)
[]Due to security settings
[]The use of a NoScript plugin to only allow scripting on certain sites
[]The user has completely disabled scripting[/list]

For example. some users (especially security experts) consider that XSS is such a danger that they don’t dare risk enabling scripting due to the potential damage that can cause.

Steve Gibson is a good example of a security expert who automatically disables scripting.

102

I don’t think people that are using Lynx expect live support chat to work there, or any desktop-like application in that case.

So NoScript does allow you to control your security settings. People who have it completely disabled, I guess, know in advance that live support chat is not available for them in their environment and would use phone instead. It’s just matter of choice.

103

Accessibility is the most important reason to allow for the lack of scripting capability, if you run a business website (something that makes money) and your website isn’t accessible to individuals who cannot make use of scripting (which would include a great number of disabled individuals) you run the risk of being sued for violating disability discrimination laws (worldwide). There are past cases of disabled individuals winning cases against large organisations because their lack of compromise for those who need it resulted in the same kind of degrading behaviour as not allowing wheelchairs into a store. Every web professional knows that progressive enhancement is the best way to develop (so those without a technology can still use the site at a basic level) and WAI guidelines back up the legal standing with notations towards alternative usage methods when a technology is unavailable. :slight_smile:

104

It’s best to develop a website so that you have HTML and CSS (with whatever server-side language and database server behind it) so that anyone can use the site, even when they have javascript disabled. Then add the javascript but don’t add it in a way that a user can’t no longer use the site if javascript is disabled.

To test how useable your site is with javascript disabled you can use the web developer toolbar for FireFox to disable javascript and explore your site to get an idea how how usable or unusable your site is with javascript disabled.

105

While this is true for websites, this topic originally was about desktop-like web applications that for sure have different development techniques from websites.

106

Provided that a site can still work work with javascript disabled then it can still work as a desktop-like web app. Mainly by the use of AJAX.

107

It won’t be a desktop-like web app with js disabled then. Reloading page on every button click doesn’t sound like “desktop-like” at all.

108

That is primarily because a the web browser is not a platform for desktop applications.
If you want to fake it and make it look like the web browser is a desktop application, you will require scripting.

Given that though, to what extent should you provide support for the less capable members of society?

109

It isn’t but it is as close as you can get given that you can’t rely on anything beyond HTML being supported by the browser - everything else needs to run on the server if you want to make sure it can always run since JavaScript is completely under the control of the person who owns the computer running the browser.

If you want anything closer to a desktop application than that then you need to build a real desktop application - the easiest way to do that if you want to use JavaScript is using Adobe Air as the program it will run in instead of trying to run it in a browser.

110

I don’t think people that are using Lynx expect live support chat to work there, or any desktop-like application in that case.

You should check out ratpoison. Lynx does not currently have this capability but many have considered it. RP is a windowing system.

111

Sorry but I used to work as a software developer and have to disagree with what you have just said. Applications do a version of a “refresh” action when something is triggered, especially when it affects the visible display region (the GUI canvas), this is usually known as a “redraw” action of the window GUI. The only difference is that within a compiled application, the action is barely visible because the change is triggered immediately (in the same way that an animation is triggered through refreshing and gradually changing frames), with a web application it has a delay between the server request and the file download therefore the refresh is more time consuming and visible. If you are trying to claim that your “reliance” on JavaScript is purely to omit a refresh, it’s pretty selfish. Refreshes shouldn’t be eliminated purely to spite them as it takes a lot of casualties in the form of accessibility users, is it seriously worth violating 10% of your potential user base just to avoid an action which is widely accepted? I certainly don’t think so and neither would anyone who takes issue with dependence on client-side scripting. :slight_smile:

112

Yes, I know how software applications work, but don’t you think there would some different approach taken in software development, if from the start one “redraw” was taking at least 3 seconds to complete?
I don’t think anybody would redraw often, because it would be unusable.

It’s not my “reliance”, it’s just how everybody develops complex web applications (I’m not talking app like twitter here). For example, I never saw any web word processing software with refresh on each action, because they just not built to work without scripting.
Maybe it’s not right to somebody who cannot browse with scripting, but it’s just how web apps work.

113

Sorry but you can’t claim that the refresh mechanism is “un-usable”, it is usable, you just don’t happen to approve of waiting for a refresh in order to achieve the function. Granted refreshing would be unsuitable for something like a menu system (like dropdowns) however that isn’t an issue because it can be achieved with CSS alone. For complex actions like passing data or commands a refresh is perfectly acceptable… and has been for many years, if your trying to claim that refreshes make web apps un-usable, then you are claiming that every web application built before the AJAX revolution was unfit for purpose. Your generalization about how “everyone” produces web applications is downright wrong however, not everyone immediately forms a drug-like addition on JavaScript. No-one is saying you shouldn’t use JavaScript, what they are saying is you should have server-side scripting (the refresh action) in place so that WHEN scripting isn’t available the app will still work - granted it’ll work with the refresh, but it’ll still at least function. The JavaScript will still be there for those who can make use of it and no refresh will be required, but having a JS free solution is at least one up on what you currently have… something which is incompatible for about 10% of everyone. :slight_smile:

114

I did not claim refresh as un-usable overall, just a refresh taking 3 seconds to complete.

So for example, if you click to make selected text bold in web word processor and it took 3 seconds to do it, it would be acceptable?

Could you give an example of complex web application build before AJAX? Similar to a word processor.

Well, if what I say about everyone’s way of developing web apps is downright wrong, could you give an example of the same example of a web word processor working without AJAX with server-side scripting?

115

So what your saying is it should be an “all or nothing” scenario? Surely it makes better sense to use JavaScript (by default) so for 90% of people it’ll work without a refresh and for that 10% who don’t have it, the app will work using refresh. You really only have two options here… either that 10% who can’t use JavaScript either have a working version that relies on refreshes… or they get told to effectively “get lost”, the latter is what you are claiming is the method which should be implemented, I happen to disagree. Server-side scripting would after all be the alternative, not the general function. :slight_smile:

PS: You seem to be taking this discussion to mean server-side scripting should be used instead of JavaScript, no-one is saying this, what we are saying however is that it’s advisable to have a fallback mechanism because not everyone has access to JavaScript and you shouldn’t punish them for this problematic scenario.

116

This is not the method I’m claiming should be implemented, this is the method it’s done by others. If you disagree, please show me web application that does otherwise and works with js disabled (as I stated earlier similar to word processor complexity).

117

I don’t know of any which do work with scripting disabled however that doesn’t mean that it’s a bad idea to develop an alternative (and I am sure it’s possible to achieve somehow - even if the alternative is a textbox with a live preview window which is generated via server-side scripting using an iFrame). The facts are that if you rely on JavaScript, 10% of people won’t have access to the application and you violate disability discrimination law, and I think that’s bad by any standard. :slight_smile:

118

As an example of a web application that works properly without JavaScript and which for some people works better with JavaScript enabled => Google GMail <= of course their JavaScript is garbage so for a lot of people you are better off turning the JavaScript off and using the application without it so as to get better reliability.

119

Gmail does not have complexity of word processing software, you can easily make mail client with html only, which how it was done before gmail. Saying that, it does have some functionality stripped down without js (for example, advance message editing)

General statements like that does not have enough credibility behind it. If their javascript is not working, gmail would not be used by a lot of people.

120

Hm I was thinking about this when I made my counter (my first “real” javascript lawlz… with lotsa help from paul wilkins). Instead of trying to refresh the page every single character that’s typed in (seriously there is NO point in doing that) I gave those without scripts a text input with a maxlength. This isn’t great and wonderful, just barely functional. Typing into a one-line text input does suck major balls, but people can do it, and they’ll be shown when they’ve reached a limit.

Textareas I found don’t have maxlength. For whatever reason. So those with scripts on get a textarea in place of the text input and a little span appears underneath that counts as they type, so they know when they get near the character limit (and then the script also stops them from adding more, a sort of scripted maxlength).

There’s seriously no way I’d want to do that with refreshes as a scriptless user. No way at all. Who wants to refresh at every keystroke?? Not me, that’s another reason to avoid lightboxes for instance… slow as hell.

When I did my schooling, we had web-based applications which we accessed from school computers. They were all Flash (and apparently very expensively-done Flash… not Flashy but extremely competent in dealing with whatever users may throw at them). I’m pretty sure they did this because only with scripting on the client side could they imitate a desktop application, yet for I guess logistics reasons they had students access it via the web. I suppose it’s reasons like this that Java is also popular. Students could try accessing material from home with their login but many could not get it working (their computers missed one thing or another). The test we were required to take was also all Flash, and fairly well done. The tests and the lessens were meant specifically to reach people who may have come from an area in the world where electricity doesn’t exist… or are simply new computer users. They were written with usability in the forefront.

However unlike a loose-running web app in the wild, these were for the most part only accessible to students who were logged in at school. That makes a big difference.

I agree that it would be pretty impossible to do at least half of the things with pure HTML and CSS (even Javascript would have been iffy). What igv is talking about, these are the kinds of programs who have regular, constant, second-by-second interaction as their basis and that’s not something you do with refreshes. The script-less version would really truly have to be something entirely different, not a slightly degraded version of the scripted version. Which I guess something offered to Everyone loosely on teh innerwebs would have to be. Sucks for the dev but there should just be two different versions, totally different.

To tell the truth, for something that really needed to work that fast and that well, you might as well just make a downloadable version with its own virtual machine or something, and if someone’s lucky enough to have scripts on, then they also have the extra ability to actually use it online.