How to build a desktop like application interface using JavaScript?

Agreed. In fact writing applications with ExtJS feels pretty much like working with C# or Delphi. The underlying HTML and Web environement is (almost) completely abstracted, you just end up manipulating GUI components.

The learning curve is really steep however.

I disagree. I rolled my own (incorporating various third-party packages) to provide shortcuts for common operations that typical DOM-centric JavaScript “frameworks” don’t address. The resulting code reusability has saved me countless hours of work. But I only have 10+ years of “inexperience” with JavaScript, so what would I know? All I really know is that I prefer a predictable and repeatable information architecture and interchange protocol to the jQuery-based spaghetti code I see on every site.

What common operations does JQuery or MooTools not include? Also, I am completely for extending functionality on top of a JavaScript library to include custom things that you need. That’s fine. But starting from the ground up puts you in a place you don’t want to be. Suddenly you now have to worry about testing your own framework. And cross browser compatibility. And upkeep / efficiency work. I think it’s much better to have that side of the workload be on the developers of the library.

You probably see a lot of spaghetti code because JQuery is the easiest to pick up, and the more new people using it the more instances of awful code you will see. Same thing with PHP, even the tutorials show off awful code. Code quality is independent of the underlying library. However, MooTools does have more logical naming conventions and function returns, and it has the built in class definition system, so I personally find writing elegant code easier in that.

But why would you want to worry about developing your own library? They’re designed for code reusability just as much if not way more than your own personal library. And extending them is a safer bet then trying to reinvent the wheel to get a few custom things.

Okay - blindfold yourself so you can’t see anything. Now when you access the web the web reader you are using to read out what the web page says will allow you to navigate things perfectly well as long as you have JavaScript turned off (assuming your web reader even supports JavaScript). With JavaScript turned on chances are that things will happen that you know nothing about because the JavaScript has done things to the page that the web reader doesn’t know about in order to tell you what happened.

Now download an application to run separately outside the web reader (or just pick one that is already there). That application will typically use the standard windows interface for all of the standard functionality within the application which the program that you are using to talk to you to tell you what is happening on the screen that you can’t see recognises so that it can tell you exactly what you are doing.

So with the appropriate software installed on your computer to cater for the fact that you can’t see the standard web pages without JavaScript are usable and the regular applications installed on your own computer are also usable. While it is possible for someone to write the JavaScript for a web page in such a way that the page would still be usable so many sites don’t write their JavaScript that way and so the only safe option to ensure you don’t end up in a total mess is to keep JavaScript turned off in your web reader.

Perhaps if you keep the blindfold on while you actually write your application you’ll be able to make absolutely certain that it works properly for all users. Of course you still have the problem that not all web readers support JavaScript at all.

I’d suggest looking into Cappuccino and [URL=“http://280atlas.com/”]Atlas

There’s loads of different frameworks you can use for scripting (in relevance to making an application which can run offline) but I think the important thing you need to consider is the method of producing the executable code. I would give the thumbs up to Adobe Air because it’s a pretty solid framework but arguably you could even use something like Titanium. For scripting the GUI I would probably go with jQuery, granted it’s not really an API style environment but it would do the job. :slight_smile:

PS: Mal isn’t that weird? A JavaScript framework called Atlas? Considering Microsoft released an AJAX for ASP.NET framework called… Atlas. :rolleyes:

Overall discussion so far is heavily concentrated on, one should create 2 versions of application or not, i.e. one with JS support and one without.

Or apart from people have discussed this which library is best to use, or which one they preffer.

The discussion is very informative and what i get from this so far is:

  1. A Non JS version should be created for a web application.
  2. We can avoid Non JS version only if we have very niche client-base. who are technical enough to understand the difference.
  3. I should not create my own JS Library, until existing libraries are not able to fulfill the requirements.

Still i did not get the answer to my questions. :injured:

Thanks.

Well to be honest I would say that an offline web application should be the same as an online one, the only difference is the manner in which it’s accessed (executable file with everything compressed within) rather than everything being located on a server. I would say make a single version of the application, then copy all of the components to an offline environment (wrapping them up in an executable so they will run natively). :slight_smile:

Cappuccino writes code that’s happy in either the browser, or runs natively on the desktop. Proof is in the pudding, the Atlas IDE is written in Cappuccino and runs in either the web browser OR as a native app.

Mal, I think you misunderstood me, I was just saying it’s weird that someone made a JavaScript library which uses the exact name “brand name” as an AJAX framework Microsoft created. I didn’t even know about Atlas (the one you linked to) until you posted it, however I was aware of Microsoft Atlas (the ASP.NET AJAX framework).

@felgall

While we’re getting off topic a little bit, I’d still like to respond.

I guess you’re only reason for doing so is blind users. I don’t want to sound like a jerk, but from a business standpoint it just doesn’t make sense. There are est. 40 million blind people worldwide, which is only about .6% of total world population (and est. 70-80% of those can have their sight restored through various methods).

What you’re suggesting is that we double our work for .6% of the viewers for something, that by it’s very nature, is visual? I completely understand the point of doing this for general population sites like Google, Wikipedia, Dictionary, which are primarily information sites in which JavaScript can be used to enhance the experience.

But RIAs are now something which is almost impossible (certainly impractical) without JavaScript. Take for example a “web page building” site using something like TinyMCE. You can’t strip that out and use something non-JS and expect it to even work. Even if you did make it work, it would be so user-unfriendly for the blind people, there’s no point.

It’s like saying you need to make a paintball arena friendly for blind people. It’s completely counter-intuitive to the entire purpose of the interactivity.

While blindness is a terrible and unfortunately disability, and I would never wish it on anyone, it’s inevitable that there are things those people are not going to be able to do. They’re not going to be able to play paintball (effectively), or drive a car, or appreciate a painting. Deaf people aren’t going to be able to listen to music. It’s an unfortunately truth about the world we live in.

Many times, it’s simply cost-prohibitive to build a real RIA in such a way that is conductive to screen readers. It can put you in the hole so far (financially), there’s really no point in building it in the first place. Not to mention the cost for bug fixing, upkeep and new features.

That’s my 2c.

telos, I work in accessibility and usability and I would just like to point out that blindness is just the tip of the iceberg when it comes to web accessibility and the problems that can face visitors, if you take into account every possible debilitating factor which could cause problems with the browsing experience on the web, it’s probably closer to 90%+ of all people who suffer some form of factorial issue which could be seriously damaged by a poorly implemented rich internet application (in terms of accessibility and usability aids). There is a reason why accessibility has become a very important issue (and people are getting sued millions over not being accessible), it’s easy to see disability as something as obvious as blindness but your misappropriating the term and ignoring the wider issue at hand. Whether it’s “cost effective” or not (in your viewpoint), you can make a site rich in JavaScript accessible, but you need to take the visitors needs into account when you start costing the process (in how much it will require to develop), only a foolish individual would write off making their product accessible out of the sake of trying to reduce expenditure, as the cost to your income or potential legal issues could be much greater, making a web application accessible is not counter-intuitive, it’s reasonable. :slight_smile:

:eek2: 90%! I must be really fortunate then, to have all 10,000 paid monthly subscribers to my RIA be completely disability free! Either that, or they’ve never mentioned it.

I guess I group people into two different categories. Basic, plain old visitors and users. My public-facing website, for all to see, is certainly accessible to everyone. However, my RIA, which people must register and pay for, requires JavaScript.

Since inception (4 years ago and $4 mil later), we haven’t had a SINGLE visitor or subscriber ask if it was accessible or complain that it wasn’t.

While you’re statement might well be true about the % of people with disabilities, I’ve certainly never encountered it. If it IS true, than it would be more cost effective to just eliminate JS (or name your technology or method here) altogether, since we’d actually being doing all that work for only 10% of the population.

Actually it’s just about being sensible, most people don’t even factor in basic things as potential accessibility issues. For example small clickable areas or reduced size text, it’s not just blind people who may have issues, people who are partially sighted (the elderly population for example) or people with color blindness may suffer ill effects (in that case it might be color contrasts). Think of any kind of disability which might impair vision, hearing, motor skill, cognitive or psychological states, you are looking at something which can be problematic on many levels and most people won’t even consider it (it’s only the most serious disabilities you really hear about because their the most drastically affected), most other people just struggle along thinking it’s normal. Trust me the people are there, they just don’t tend to come forward as most people are embarrassed about talking on such matters or feel people won’t listen (or discriminate against them). :slight_smile:

No - blind users are just one fairly obvious example. They are also a group known to take legal action and win when web sites do not cater to their needs so not catering to them can be very costly.

Extensive studies have shown that about 70% of all web users have some form of disability that has some sort of effect on how they use the web. In many cases those disabilities will not impact on their being able to use your proposed web application but it is reasonable to suppose that a significant fraction of the 5-10% of people who have JavaScript disabled have done so (even if unknowingly) as a result of their disability (which they themselves may not be aware of).

Alex has mentioned a few more of the sorts of disabilities that you need to take into account.

To get the expert view on web accessibility you should read a few of Jakob Neilsen’s books on the subject. His book “Prioriitizing Web Usability” (published by New Riders) is a must read for anyone looking to create web applications as it goes into great detail on the sort of usability testing that such applications require.

There are “many” big web applications require you to have javascript enabled. Let me name few: gmail, adsense, hotmail, yahoo mail, blackboard etc. List goes on. What i’m saying that javascript is not the thing we can avoid to build a great app.

My current project requires javascript, and it does check if user has it enabled or it will not let them go through.

Don’t get me wrong, I’m not against usability. Sites, and more importantly RIAs, need to have a no-nonsense, keep-it-simple approach, which is exactly what I do. But accessibility and usability should not be confused, though they are similar. However, I don’t think doubling your efforts to make your site work without JS is a reasonable or productive way to do this.

People that are colorblind, dyslexic, newbs or just have no idea what they are doing are going to have the same problems without JS as with. The MAIN group of people who have problems with JS are blind users using a screen reader.

But, if you are requiring the user to pay for a subscription for your service or RIA, I don’t believe it is unreasonable to require them to use JavaScript. As I’ve said before, things like Wiki, Google, Target, Yahoo, to name a few, which are made for the general population, without registration, should probably cater to the folks with disabilities.

It is neither productive, beneficial or profitable for me to build my RIA twice (or close to it), for a small fraction of users who can’t use JS. It IS productive, beneficial and profitable for me to build it in a way that makes sense, is clear and understandable, and is easy to use. It just so happens, that JS allows me to do things that make the RIA 10-times easier to use.

It’s like that old saying, “if you can’t take the heat, get out of the kitchen.” If you’re not willing or able to use JavaScript, than my site is not for you.

It’s an approach that has worked very, very well for me for several years, and - as long as it is profitable - I’ll continue to use it.

My own view (and it’s how I’m doing my site) is for a site to be coded with just HTML and CSS (with whatever server-side language and database server as appropriate) with any javascript added as an optional extra but not necessary for a site to be usable and accessible.

Javascript should not be added just for the sake of it but used where it could improve a user’s browsing experience where appropriate, for example the use of AJAX to only reload/refresh parts that have updated something, like a received PM notification.

AdSense does require JavaScript and anyone without JavaScript just sees the web pages without the ads so pages using AdSense still work without JavaScript.

GMail also works without JavaScript - in fact since the JavaScript used contains garbage GMail actually works better without JavaScript and is a good reason for turning JavaScript OFF.

I can attest that Gmail totally doesn’t need JS. I doesn’t has it on.

Felgall is talking about web pages. Telos, what you’ve made are not web pages. They are web applications. Web applications do go against everything that was good and great about the internets (that they were available to everyone regardless of software, hardware, platform, etc… that was the original point and why stuff like .mobi was discouraged… one web to rule us all) but as people want them, I guess they’ll happen. The web will continue to fragment and once again there will be parts only accessible to the privileged few and then the web pages for the rest of us.
As a front-ender I struggle against this change in ideas of what the web is. People want the internet to be their television and their desktop.

I’m thinking the rules for the Regular Web (where things need to work with pure sever and HTML) will not be able to hold for Application Web (with all the 3rd party non-free software, hardware requirements, etc). The analogy with the gaming thing is fine. A game is not a web site, it’s an application.

Alokjain:

Overall discussion so far is heavily concentrated on, one should create 2 versions of application or not, i.e. one with JS support and one without.

If it’s really an application then you may never be able to make it work with pure HTML. HTML was created for marking up documents, not for making desktops. I’m just saying, if this really really really is an application and not a web document, you may end up doing this is some specialised programming language and not with pure HTML. There’s a reason why desktop applications are written in C or C++.

Browsers are starting to come out with some JS compiling but it’s not here yet, certainly not cross browser. The reason JS is slow is it’s run as it’s read. That’s slow.

What library you should use, and whether you can even do this without JS (or have any sort of non-js version) depends completely on what exactly you want to do. You haven’t been really specific. Are you really going to build and entire desktop online with all the junk a desktop environment can do?? Man, you ever see the size of just Gnome?? Huge. How’s anyone supposed to load that? So I assume you mean something smaller and not quite as able, right?