With the increased power of JavaScript frameworks like YUI, JQuery, and Prototype, and debugging tools like Firebug, doing an application entirely in browser-side JavaScript looks like a great way to make simple applications like puzzle games and specialized calculators.
Is there any downside to this other than exposing your source code? How should you handle data storage for this kind of program?
Edit: yes, Gears and cookies can be used for local storage, but you can't easily get access to files and other objects the user already has around. You also can't save data to a file for a user without having them invoke some browser feature like printing to PDF or saving page as a file.
I've written several application in JS including a spreadsheet.
Upside:
great language
short code-run-review cycle
DOM manipulation is great for UI design
clients on every computer (and phone)
Downside:
differences between browsers (especially IE)
code base scalability (with no intrinsic support for namespaces and classes)
no good debuggers (especially, again, for IE)
performance (even though great progress has been made with FireFox and Safari)
You need to write some server code as well.
Bottom line: Go for it. I did.
Another option for developing simple desktop like applications or games in JavaScript is Adobe AIR. You can build your app code in either HTML + JavaScript or using Flash/Flex or a combination of both. It has the advantage of being cross-platform (actually cross-platform, Linux, OS X, and Windows. Not just Windows and OS X).
Heck, it may be the only time in your career as a developer that you can write a web page and ONLY target ONE browser.
SproutCore is a wholly JavaScript-hosted application framework, borrowing concepts particularly from Cocoa (such as KVO) and Ruby on Rails (such as using a CLI generator for your models, views and controllers). It includes Prototype, but builds plenty of stuff such as sophisticated controls on top of that. Its Photos demo is arguably impressive (especially in Safari 3.1).
Greg already pointed you to Gears; in addition, HTML 5 will come with a standardized means of local storage. Safari 3.1 ships with an implementation where you have a per-site SQLite database with user-settable size maximums, as well as a built-in database browser with SQL querying. Unfortunately, it will be a long time until we can expect broad browser support. Until then, Gears is indeed an alternative (but not for Safari… yet!). For simpler storage, there is of course always cookies.
The downside to this would be that you are at the mercy of them having js enabled. I'm not sure that this is a big deal now. Virtually every browser supports js and has it enabled by default.
Of course the other downside would be performance. You are again at the mercy of the client handling all the intensive work. This also may not be that big of a deal, and would be dependent on the type of app you are building.
I've never used Gears, but it looks like it is worth a shot. The backup plan would be to run some server side script through ajax that dumps your data somewhere.
Not completely client side, but oh well.
Nihilogic (not my site) does a lot of stuff with Javascript. They even have several games that they've made in Javascript.
I've also seen a neat roguelike game made in Javascript. Unfortunately, I can't remember what it was called...
If you want to write a standalone JavaScript application, look at XULrunner. It's what Firefox is built on, but it is also built so that you can distribute it as an application runtime. You will write some of the interface in JavaScript and use JavaScript for your code.
Gears might provide the client-side persistent data storage you need. There isn't a terribly good way of not exposing your source code, though. You could obfuscate it but that only helps somewhat.
I've done simple apps like this for stuff like a Sudoku solver.
You might run into performance issues given that you're completely at the mercy of the client's Javascript interpreter. Gears would be a nice way of data storage, but I don't think it has penetrated the market that much. You could just use cookies if you're not fussy about that kind of thing.
I'm with ScottKoon here, Adobe AIR is great. I've really only made one really nice (imho) widget thus far, but I did so using jQuery and Prototype.js, which floored in such wonderful ways because I didn't have to learn a whole new event model. Adobe AIR is really sweet, the memory foot print isn't too bad, upgrading to a new version is built into AIR so it's almost automatic, and best of all it's cross-platform...they even have an alpha-version for Linux, but it works pretty well already on my Eee.
Standalone games in GWT:
http://gpokr.com/
http://kdice.com/
In regard to saving files from a javascript application:
I am really excited about the possibilities of client-side applications. Flash 10 introduced the ability to create files for save right in the browser. I thought it was super cool, so I built a javascript+flash component to wrap the saving feature. Right now it only works for creating text based files (vcard, ical, xml, html, css, etc.)
Downloadify Home Page
Source Code & Documentation on Github
See It In Use at Starter for jQuery
I am looking to add support for non-text files soon, but this is a start.
My RSS feeds have served me well- I found that Javascript roguelike!
It's called The Tombs of Asciiroth.
Given that you're going to be writing some server code anyway, it makes sense to keep storage on the server for a lot of domains (address books, poker scores, gui configuration, etc.,.) For anything the size of what you'll get in Webkit or Gears, you can probably also keep it on your server.
The advantage of keeping it on your server is two-fold:
You can integrate it fairly simply as a Model layer in a typical MVC framework, and,
Users get a consistent view without being tied to their browser/PC, or in a less-than-ideal environment (Internet Cafés).
The server code for handling this can also be fairly trivial, particularly if it's written with this task in mind, so it's not a huge cognitive burden.
Go with qooxdoo. They recently realsed 1.0, although most users of it say it was ripe for 1.0 at least two versions ago.
I compared qooxdoo with YUI and ext, and I think qooxdoo is the way to go for programmers - YUI isn't that polished as qooxdoo, from a programmer's point of view and ext has a not so friendly licensing model.
A few of the strong points (for me) of qooxdoo are:
extremely clean code
the nicest OO programming model I've seen among Javascript frameworks
an extremely rich UI widget library
It also features a test runner for unit tests, an API doc generator and reader, a logging facility, and several useful features for debugging, grouped under something called Inspector.
The only downside is that there aren't readymade themes (something like skins) for qooxdoo. But creating your own theme is quite easy.
Related
I have just begun giving JavaScript a try on a programmer friend's suggestion (though I have used it to some extent before with websites using jQuery without fully understanding the intricacies of the language itself) and was wondering how certain features work.
Question:
What other uses of JavaScript are there aside from websites (by itself and/or with jQuery framework)? Is there a difference between making a site interactive and an actual "web app"? I've heard the term and don't know the difference.
To add to my main question:
I've read and done some tutorials on prototyping and am not sure on its actual application (since what little I've dabbled in, by making a website more interactive, I've never seen them used). Can someone link a website with extensive deep/heavy JavaScript use so I can check it out?
Gist:
In essence, what I'm trying to understand is where heavy use of JavaScript comes into play because so far, all JavaScript I've experienced is superficial.
Appreciate in advance any advice/help in this matter!
What other uses of Javascript are there aside from websites (by itself and/or with jQuery framework)?
Check out node.js. It runs JavaScript programs not intended for web use. Node offers a bunch of imports for things like file system IO, socket IO and a bunch of others. I personally use it for a WebSocket server because I don't like my alternatives.
Further, JavaScript has native support in many operating systems, including all Windows versions after and including XP (not sure about before). Windows Script Host runs .js files as JScript and these can be used to achieve things like those node can. It's a convenient way to do things batch can't.
So I have this project I'm working on and I'm trying to build the website part of my project. I have experience with Flash AS3, but not so much or none with JavaScript. My co-workers are telling me that they are almost the same and you can just build the site in JavaScript. But people can have JavaScript turned off, and not everyone uses Flash.
I'm having difficulty knowing what to use to build my website...by the way, this website is generally an application. It's going to have a menu with features and stuff. I figured I can probably do HTML and PHP, but there's some features I need that will be dynamic. I really want this site to be available to as many people as possible.
The only reason (again) why I would use flash is because I've used it before and it's easy to design with animations and junk.
I could use some advice.
This is my personal opinion, but if you can meet the needs of your application with HTML and Javascript, you will probably be much better off. Your application will not require Flash, will likely load faster, will work better on mobile devices and will work on iDevices which do not support Flash at all.
That said, there are some challenges to building some types of applications in HTML and Javascript, particularly if you need to work across a wide range of browsers. Using a popular library like jQuery or YUI can help with a lot of that cross browser compatibility, but some capabilities are only available in the more modern browsers.
On the opposite end of things, some things can be done better in Flash than in HTML (particularly in old browsers).
So ... the answer is that, it depends on the needs of your application. If it were me, I'd build it in HTML and Javascript unless I found a reason that I couldn't make a successful application that way.
As for computers with Javascript off, it's my opinion that those computers are not doing modern things on the web anyway and would not likely be customers of anything I'd build on the web. Google has dropped support for computers without javascript and some old browsers from some of their apps because the cost of development for those cases is way higher than the benefit from the few customers you might gain by it. Whether that logic applies to your application obviously depends upon what you're doing and who it would appeal to.
If you looking to use javascript, there is jquery which is very easy to use and very rich in functioanlity. There is also extjs which is also easy and functionality rich but its not free for commercial use.
If you are new to javascript and already know java, you can use Google web toolkit where you write the code in java and the toolkit compiles that into a javascript. But this depends on how much server functionality you have.
IF the website is a simple one, you can probably use jquery, html and css.
If its a commercial project I would use Flash because You're good at it and You will build the app faster.
If You want to take a fascinating journey with the most popular language and develop Your skills then use javascript.
Flash and javascript are both very popular. For both methods You can use a fallback if the technology is not available.
If You decide to use javascript consider using backbone.js. It's a great MVC library.
Many years back, I was told that Javascript was harmful, and I remember being annoyed with endless popup when I right-clicked an image to download it.
Now it seems suddenly that Javascript is great, and you can do a lot of things with it to let users have native-like web application experience.
I admit I have missed 6-7 years of Javascript literature, so I hope to start anew with SO kickstarting me to understand the following:
Is Javascript mainly concerned about user interface i.e. smoothen interaction between application and users and not about logic processing, number crunching or form processing etc.?
Can Javascript write to local hard drive (besides cookies)?
Can Javascript web application run with Javascript capabilities in browsers turned off? (I would think outright no, but an article on Adaptive Path said 'maybe')
Is AJAX illegal to use due to Eolas patent claim? Is it worth it spending effort learning it when the future is not secure? (I know AJAX is not Javascript)
Thanks. Hoping for enlightenment.
Yes. JavaSscript is usually used to enhance the user's experience and make the site easier to use. It is also possible to delegate validation tasks and the like to JavaScript, however (though this should never absolve the server of its responsibility to check input).
No.
That depends on how the application is written. If it's done properly, then the JavaScript will merely enhance the interface, and the application will still work without it; this is called progressive enhancement.
Not at all. AJAX is used extensively on this very site!
One reason for the resurgence of popularity for JavaScript lately is the emergence of several frameworks. These make the process of writing JavaScript much, much easier, allowing tasks that would previously have been horribly complex to be implemented with minimal time and effort. The most popular of these is jQuery, which is a good place to start if you're intending to get in on the action.
Overall, JavaScript is a very powerful tool that allows you to create very rich interfaces. Well worth learning.
Yes, Javascript is all about client side processing, but also about AJAX where it calls back to the server asynchronously so that users do not see pages reloading.
No
No, but there are ways to gracefully degrade the experience for non javascript users. It requires carefult planning however.
No, that lawsuit was just about the browser technology that enables it. As a developer you dont have to worry about that.
Can Javascript write to local hard drive (besides cookies)?
Not really. However, as HTML5 support becomes more widespread you'll be able to use things like Web Storage and Web SQL. You won't be able to write arbitrary files on the user's hard drive, but using those two technologies you'll be able to persistently store and access data.
Can Javascript web application run
with Javascript capabilities in
browsers turned off? (I would think
outright no, but an article on
Adaptive Path said 'maybe')
It really depends on how you define "web application." You can write web apps without using Javascript for anything but UI candy, in which case you can degrade gracefully without without it. However, it's also possible to write web apps that rely heavily (entirely, even) on Javascript, which will utterly fail without it.
Is AJAX illegal to use due to Eolas
patent claim? Is it worth it spending
effort learning it when the future is
not secure?
I'm not a lawyer, but I'd agree with the other answers -- you shouldn't worry about it. I'm certainly still writing AJAX stuff :)
Is Javascript mainly concerned about
user interface i.e. smoothen
interaction between application and
users and not about logic processing,
number crunching or form processing
etc.?
It's about both. And more than that.
Javascript has really come into its own in the past few years. Browsers have gotten a lot faster at executing it quickly, and people have been figuring out new ways to use the language itself to its full potential. You can really start using Javascript like a full-out application programming language, and not just to write little scripts that animate something or validate input.
If you're just getting back into the language and haven't read Crockford yet, I would highly recommend it. It's a great starting point to realizing the full potential of Javascript.
Edit: Some good Crockford Links
Javascript: The World's Most Misunderstood Programming Language
Javascript: The Good Parts (This is a presentation. Crockford also wrote a book by the same name that I haven't read myself, but I hear it's quite excellent.)
It's mainly for UI, but it can be used to save server-time on some operations (for example, Mathoverflow uses it to render LaTeX) and it's becoming popular to do so. But when you do this, you need to be respectful of the end-users time, because JavaScript can hold up some browsers, while it runs. But in general, it's a good and interesting idea.
Not without permission
If it's written correctly, it can. It's called "Graceful degredation" (some other variant terms exist, but the idea is the same). The basic idea is that you have it such that the JavaScript fails 'gracefully', and links that would normally get handled via JavaScript (i.e. to do some inline next-paging) will navigate to a 'backup' page that shows the relevant content.
I don't know about that, but AJAX can be implemented in different ways, XMLHTTPRequest is just one of them :) (And the most common, and suitable). Generally you like a library do this for you anyway (jQuery, or otherwise) but you can do it yourself for fun.
Yes, in my experience JavaScript is generally used to create a streamlined interface and relays information from the client to a server application for processing.
Yes, if the browser is configured to allow this (most aren't by default since this can be very dangerous).
No, JavaScript will not run if the browser is configured to have JavaScript disabled.
I wouldn't forgo learning JavaScript for this reason - as for the legality of the whole thing I wouldn't feel comfortable advising you about this. Still I think JavaScript is worth learning in spite of this situation.
The Eolas patent covers the embedding of objects in a HTML document (see US patent 5,838,906 titled "Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document") ... this scope would not seem to include AJAX as a suite of technologies (being essentially scripting in a document to load content elements).
Partial answers:
I think all the security vulnerabilities associated with javascript have been fixed? IIRC the problems weren't with javascript, they were with particular browser's implementation of javascript.
I wouldn't worry about any patent claims on the AJAX technology. Patent sueing and counter-sueing is common place in the software world and invariably ends up with the affected parties licencing each other's technology. AJAX is not going anywhere :)
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.
I come from the Microsoft world (and I come in peace). I want to rapidly prototype a web app and if it works out, take it live - and I don't want to use ASP.Net.
I am not sure which web application toolkit to use though. Should I use GWT, DOJO...other recommendations? I am open to any server-side language but am looking at RoR, Php or even Java (J2EE to be precise). I am not much of a Javascript/CSS guy so a toolkit that might make it relatively easy on me on those fronts would be preferable.
Also, I am a mac user at home. What IDEs go along with the framework you would recommend?
Any recommendations guys?
If you're open to doing Java, GWT is the way to go. It allows you to have a relatively uniform codebase across client-server, and to only use one language on both.
There are some limitations to doing very off-the-beaten-path AJAXy things (which GWT makes difficult, but not impossible), but it doesn't sound like that's your use case anyway.
GWT will allow you to scale up by using more of its features as your app gets more complex - and your prototype won't be throwaway code.
If you want to write the front and back end in JAVA, and want to do complex ajax type thing, then GWT is a great way to go.
The easiest way to think about it is that building a GWT app is kind of like building a JAVA swing application that hooks into a server. Just like a swing app that uses a server you can make it fat or thin. When you're done it all compiles down into HTML and javascript, and has very good modern browser support (ie6+ ff, opera, safari).
It does abstract all the javascript and HTML away, but if you want it to look good you'll still need to understand CSS.
I think anyone who says that that it ruins MVC or that it's a muddying of client vs server doesn't understand GWT. GWT is a CLIENT side framework. And it is only used on the CLIENT. GWT does provide an RPC mechanism to hook it into JAVA (and other) back ends, but that's just a communication protocol, it doesn't mean that your server code magically becomes your client code. Sure you can write a whole bunch of business rules into your UI if you really wanted to, but you can do this with any framework, so it would be silly to say that GWT is somehow different in that respect.
GWT is a good choice, while if you choose more powerful JavaScript framework based on GWT (e.g. SmartGWT), the compiled stuff is too heavyweight.
Choose direct JavaScript if you need a compact project.
I am a fan of GWT, however I am very familiar with Java. I found it to be intuitive, and surprisingly easy to get good results quickly. If you are to use GWT, then you'll definitely want to use the free, and immensely powerful Eclipse IDE.
One disadvantage of GWT is that it requires Javascript to be supported by the browser, there is no "graceful degradation".
We have evaluate a large list of frameworks and have decide us for Echo2.
You need only to code in Java. Javascript you need only if you want write your own components.
There are no startup performance problems with large projects like GWT.
You can use the full range of Java in your client code because it run on the server. In GWT you can use only very small set of Java classes.
The IDE for Java is Eclipse. This is independent of the used framework.
I'm a fan of jQuery, the chainability of actions, traversals, and commands is really powerful. A good friend of mine is crazy about Mootools, he works at a Java shop FWIW. He mentioned a cool feature of Mootools is that you can specify the functionality you want the framework to include and it will generate the entire library on a single line in a file that you can include on your page to minimize the weight of the framework (pretty cool feature). Really it just depends on what you are most comfortable with. jQuery has great tutorials, is super fast, and can be used along with other javascript frameworks.
Not related to GWT, but have you considered other backends that GWT could work nicely with?
Grails is one backend that ties quite nicely with GWT.
Personally, I would avoid server-side frameworks that try to embed or hide the client-side framework. I'm sure that GWT is great for getting something going quickly, and is probably fine for certain kinds of applications, but you'll probably run into lots of problems "on the edges" for more complex applications. Decoupling the client framework from the server-side framework avoids those problems.