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.
Related
I am building a web application that uses a lot of Javascript. Now I am wondering does it make sense to make the application work without Javascript? I can understand for normal websites that you want to make sure everybody can use it but can you say the same of complex web applications?
I checked out some big web apps and it seems some do it and some don't. For example GMail has a basic version that works without Javascript.
If you look at Google Docs it doesn't work at all without Javascript. Creating an app like GDocs without Javascript is most likely not possible.
Is that a good standard to go by: if it's impossible to fall back to a non-Javascript working applicaiton you don't do it?
It really depends on what is your project about and who is your target audience.
For projects that are rather sites/pages than applications, there should be an option to browse through with JS disabled, but it's okay if only in read-only mode. This very site (SO) is an example of that approach.
For projects that are rather applications and involve very complex UI composition and dependencies, there is probably no other alternative. For instance, ASP.NET projects won't work without JavaScript but nobody would usually complain given the powerful abstraction it brings to play.
I am still learning javascript and the more i learn the more i ask myself why do i need to learn a js framework like cappuccino, sproutcore, qooxdoo, smartclient etc...? The learning curve for these frameworks is steep, also wouldn't it be better to just make use of JavaScript libraries?
Take note, that my objective is to create desktop like web apps. Thanks in advance for any good view points!
Desktop apps are built with frameworks that are of the same quality as those from SproutCore, Cappuccino, etc.
If you want to build desktop quality apps with true MVC architecture you can either write your own framework on top of a library, or start with a framework someone else has written. (SproutCore was originally built on top of jQuery for example)
The best part of a true framework is that the build tools can include only the pieces needed to run your app resulting in very small code with rapid load times.
Seeing as you are still learning Javascript, I would suggest that you continue to work with Javascript, and try out tools like jQuery, and then depending on the individual application you are working on, evaluate whether you need to use a more full featured desktop style Javascript framework at that time - something that will require a knowledge of jQuery/Prototype/etc to evaluate.
IMHO, those JS frameworks you mentioned are overrated bloatware.
I would wholeheartedly recommend that you learn JQuery instead.
It is a much more minimallistic and elegant framework.
Also, by the time IE 9 finally ships earlier next year, all the browsers
will be supporting most of the HTML5 standard, including offline storage and
websockets, making such complex frameworks completely unnecesary.
I am planning to build a web application highly based on Google Maps API. I am considering either using the Javascript version, or the Flash version. I would like to create an interface which will be quite rich. Should I go for JS version of the API or Flash one? Also I do not plan to purchase Flex Builder, so ideally I would like to use some free Flex SDK that supports ActionScript. What would you recommend? Is it more reasonable to use JS or maybe better use the Flash Version. What are the limitations, pros and cons?
The advantages of Flash:
Fully cross-browser/cross-platform.
Write once, run everywhere (except
iPhone & iPad).
Virtually same syntax
as Javascript, only with class-based
OOP, strong data-typing, etc.
Very fast UI effects (high frame-rate, etc.), much faster than JS/HTML5, way less CPU usage
Disadvantages:
Steve Jobs hates it.
Hey, I've built apps using both the Flash and the JavaScript version of the Google maps API. I find that there's not too much difference between the actual API itself. However, I find that creating apps with the Flash/Flex version is much easier because you get a real component based environment to build your app. In my opinion this leads to much cleaner code and maintainable applications whereas the JavaScript applications tend to get messy.
I do not know how it is to develop Flex apps without the FlashBuilder but I guess it's doable. In the end it's a good investment.
Go for Flex....
Fully cross-browser/cross-platform.
You can find a lot of articles and support.
Coding wise its strict and neat compared to JavaScript which is loosely typed language.
You can find a lot of custom components and third party API's which can bring more rich look and feel as well as high usability.
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.
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.