I have a question about GWT. I know that (I suppose it's correct) logic of an application written with GWT is uploaded to client UI. So everyone can see how I "coded" and all my algorithms (it's javascript) !!! then concurrent enterprises could cheat my algorithms !!
I want to know if there a built-in secure mecanism in GWT to avoid that.
Thanks
Don't worry,GWT Takes care of it.
By default, GWT obfuscates the JavaScript it produces. This is partly done to protect the intellectual property of the application you develop, but also because obfuscation reduces the size of the generated JavaScript files, making them faster to download and parse.
Why is my GWT-generated JavaScript gibberish?
However,if you want to make your code human readable you can compile with style -PRETTY .
I don't agree. I think logic stays on the server side and it's invoke as a callback for events generated by user interface (of course if you code your application well.) If you fallow this https://developers.google.com/web-toolkit/articles/mvp-architecture you will have logic and UI separated. Anyway js generated by GWT is not humanreadable (not sure if there a tools to convert it to humanreadable instance).
Related
I've made some a couple of chess engines in Processing (a simplified Java language) and wanted to make one on a website. I'm guessing JavaScript would be the most obvious thing to make it in, but I wanted to know if there are other options before I get into it. I've never made something that processing intensive for web.
I've looked around and it seems like C++ can somehow be made to work with web code but I've never done that and don't know much about it. Is it possible to do the low intensive things like drawing in JavaScript and the move generation in C++? Is there a better option?
Edit: I put Processing (the language) in bold to differentiate it
If you're looking for a cross browser client-side solution, then there is no single cross-browser way to use C++ in your viewer's browser. Cross browser solutions consist of javascript (recommended), java (being phased out on desktops and generally not available on mobile) and Adobe Flash (not available on mobile).
If you want it all client-side, what I would suggest is that you write in client-side javascript and do as much processing as you can in webworkers which are separate threads of execution. Those separate threads can do as much calculation as you want, but need to use messaging to communicate back to the main javascript thread in order to actually modify the DOM or interact with the user.
Or, as a browser web-app, you could keep the chess logic on the server in C++ or whatever server-side language you want to use and use client-side Ajax calls to ask the server to calculate the next move.
It depends upon how you want to architect this.
If you want to make it run without server-side support, you will pretty much limited to JavaScript. (Sure, you could actually host your existing Java code and libraries, available as a Java applet - or something in Flash or another plugin for that matter - but especially given HTML 5, etc., the focus is on JavaScript.)
Otherwise, you can implement the UI and other elements with JavaScript, and use AJAX to have it communicate / offload the heavy processing to a back-end server. (At this point, you would essentially need to host a chess engine for use from your website.)
Write the chess engine with any language you so desire. Create an interface for communicating with your chess engine or even better use an existing standard chess engine interface. Use either of the following two "standard" interfaces
http://en.wikipedia.org/wiki/Chess_Engine_Communication_Protocol
http://en.wikipedia.org/wiki/Universal_Chess_Interface
Once you have thoroughly debugged your chess engine and are happy with it, you can approach the problem of writing a web UI for it as a completely independent problem. You can accomplish communication between a chess engine server and a web-server/website by an intermediate layer of your choice. One such option is:
http://en.wikipedia.org/wiki/Ajax_(programming)
Furthermore, if you use a standard chess interface you can swap out your own chess engine for any third party chess engine satisfying the interface that you chose.
Given a really large, 3+ gig, binary file is there anyway that I could stream, from client to server, only portions of the file using JavaScript given that I know what byte range of the file that I want to receive?
I have a Ruby on Rails application that needs to grab specific portions of a file from the client. As one user has stated I could do this using Java.
Edit: After some reading it appears that HTML5 via slicing a file may be the best bet. http://www.html5rocks.com/en/tutorials/file/dndfiles/
The basic answer is yes, assuming your web server supports it (which many do).
You can use the Range HTTP header to request only a part of the file (e.g. Range: bytes=1000-2000). Whether this works for you depends heavily on what you’re trying to accomplish — more information would help.
See this answer for a discussion on using it.
No, not really (at least not now, anyways). The file handling capabilities exposed to Javascript is not powerful enough to really do anything useful client-side when processing files to send back to the server (including things like only take part of a file). There are proposed w3c specs for better client-side file handling for javascript, but none of the major browsers implement it to a sufficient level to really handle this case quite yet.
I'm currently working on a project with similar needs, and the only options we found when we looked into this was to either use Flash, or to use Java. Since we are much more comfortable with Java than flash, we went that route.
We are currently using Groovy and the Griffon framework, as well as Grails for the server-side pieces. Griffon has been great because it frees us from the hassles of desktop vs. webstart vs. applet, and since it's built on Groovy, it can leverage the Swing DSLs so it is much less painless to write Swing.
What is the use of frameworks like PURE or jQote etc. I can do dynamic things in plain javascript or JQuery using AJAX calls or an advanced library like DWR.
What new stuff do these templating frameworks bring to the table? I need to know since I have been asked to use a browser side templating framework without being explained why :(
I guess it depends on what you're using as your server code; it could be that the recommendation came from someone who hasn't heard about N/Velocity for example.
I think the main reason for client templating is that it removes the weight of transformation from the web-server.
It might also allow you to send your JSON from a dedicated box, and serve the template and client code from a different box.
To my mind, both of these 'bonuses' override the fact, that you're putting Data into the DOM that shouldn't be there. Firstly you'll have the JSON that is parsed by the template generator and then you'll have the HTML that is created.
Sure, viewing page source will look neat, but in terms of memory consumption for the browser it's bad, especially if you're in the UK and have Government contracts who mandate IE6 support.
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.