Web based systems (Client Side GUI only) are known to be platform independent, But, are they development-platform independent too??
To the best i know, Client Side GUI will always be built using HTML and JavaScript/VBScript or Java or etc which are supported by all OSs and Browsers to make it independent. I am concerned about the change in GUI-code if the server side platform is switched e.g. from ASP.NET to PHP or Java or from x to y?
If it depends upon the way the GUI is designed/developed then What should not be used to make this impact as minimal as possible?
Regards
Atti
You would need to use frameworks that are platform agnostic or write your views in plain html + javascript + css yourself.
Platform agnostic frameworks would help to seamlessy deploy your UI layer, or views, onto different operating systems.
If you also plan to change the development language, you will probably have to write the html, javascript and css for your views yourself because to my knowledge there are no popular frameworks that can be used on different languages.
Most frameworks are designed to work with a specific language/runtime and provide you with a level of abstraction that hides the gory html, javascript, ... details for you for a more natural development experience.
The code is then transformed by the framework into pure html, javascript, css, ...
But in case you want truly agnostic views, you will have to give up that abstraction and write the html yourself.
Not an easy task, not because of the fact that html and javascript are difficult per se, but cross browser compatibility is a bitch, plus you lose the benefit of well tested components.
The end product, on the client side, is always platform independent because it is nothing more then html, javascript and css, which is supported by all operating systems
If the client GUI is written in JavaScript and does all communication with ajax and json, you can swap out whatever back end you want as long as it provides the same api.
It also depends on how you build the site. If you are using, for example, java based html widgets, it will be harder to replace with the equivalent in say cold fusion.
But changing the back end is usually an exercise in futility since you aren't really giving the end users anything different. Often it's overzealous programmers that want to rewrite the back-end for no good reason. Don't do that.
I thought it worthy
The Web is Not Platform Independent
Typically the server side of an HTML application should not impact the client side. Meaning that if you stick to JavaScript only components on the client, you will be able to change the server side any time you want.
The problem with JS programming is however deeper than just browsers compatibility (which is already a huge problem). The following are not well considered problems:
Performance - JS is the slowest language on earth.
Inside the box - JS offers interop only with the browser DOM, and a few other things. This means that any application that wants to be "native" for a specific OS must not be implemented in JS.
So maybe you need to investigate approaches that have a "native" client UI. Such as Java for example.
Related
I've played a great many MMORTS games such as Evony, Dragons of Atlantis and Kingdoms of Camelot. They all have some great features and a great many not so great problems. Simply for my own interest I wanted to try my hand at writing something similar. I don't intend to even try to compete with the big boys but I wanted to write it in a professional and scalable manner as if it was intended for eventual commercial release.
So that's the background that leads into the question. I have been looking at various frameworks and libraries that would be suited to this style of game. However there is such a plethora of options that my head is now spinning. I would like to get some input as to what other people think are the best options. I want to try and write this as a cross-platform / cross-browser webapp that can later be converted to a "Native" app using something like MoSync. I want to stick with HTML5, CSS3 and JavaScript technology.
Some of the things I am sure I want are:
It must be scalable (ie able to handle a significant number of simultaneous users)
I prefer to work with some sort of MVC framework (I am used to working with Joomla MVC and have been considering backbone.js for this aspect)
I am no JavaScript guru but will most likely want to work with jQuery (mostly in relation to client side views)
I like templates but am completely lost which template system to go with (ie mustache, handlebars, dust etc). I think my choice in this area will ultimately come down to which framework I end up with.
Chat is an important aspect of MMORTS games and I am thinking of using Node.JS and Socket.io (or NowJS) for this.
I have also been looking at Redis for key-value store.
At this stage I have abandoned the idea of using jQuery Mobile as initial tests have caused more headaches than they have solved.
So my front runners are Node.JS for server side JavaScript (possibly with NowJS to implement chat), Redis for key-value store, backbone.js for the MVC framework, mustache (or maybe LinkedIns fork of dust) for templating and Jquery of course.
I would greatly appreciate any input to help me make my final decision on what frameworks and libraries to use.
This is not a framework, but you may find Mozilla's Browser Quest implementation interesting. The whole thing is open source and they use HTML5 Canvas and Node.js (socket.io is a big player here) and it is entirely cross-platform
I'm working with a team on exactly this. Our research and experience suggests that a Node.js backend is definitely a good idea. What to use with Node.js? We've come up with two good possibilities:
Use websockets for communication and a front-end engine like Phaser for your rendering.
Use Isogenic Game Engine for everything.
(http://html5gameengine.com/ may help you to compare the feature-sets of the top HTML5 game engines including the ones I've just mentioned.)
I've heard the Google Web Toolkit isn't that good for web sites with more than 5 pages and a common layout. Is that true? We have at least a 100 subpages and a common layout defined in CSSes. Today were using PHP but we will move to a Java front either Spring MVC or GWT. We're using som jQuery AJAX and other jQuery components like a jqGrid. We also have some .swf-films and fusion charts. Will opting for Spring combined with GWT be a good choice or is Spring MVC with a jQuery library a better choice for us?
It's not true now. Earlier GWT versions really had some issues with scalability (e.g. problems with JS code size in IE - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440), but since GWT 2.0 you have no limitations here.
Moreover, latest GWT versions support functionality for splitting projects to the parts that may be loaded dynamically when they're needed. Please refer to https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting to learn how it works.
Take into account also that since Spring is Java, you have possibility to share classes between server- and client-side. Plus Java has very good support in IDE - all kind of refactoring will be available for you (it is not so convenient in case you use jQuery).
So Spring+GWT looks more preferable choice.
GWT is not a universal framework for building just a any webapp from scratch. It is very useful when you have a lot of complicated logic on client side, (image editing, real time collaboration, diagram drawing, games , complex reports building and etc etc). But all of this can be done without GWT.
GWT can be used when:
your team hates/dislikes JS (and is unable to build nothing complex with JS, just because they hate JS)
your team is quite experienced with Java
your team understand how all this browser related stuff works (HTTP, JS, DOM , CSS and etc)
in this project there are will be a lot of logic running on client side
I've seen quite a few big projects built completely with GWT. Some of them should never used GWT, because the were no reason for them to use it in such way. For most projects it is enough to use GWT only for some part of application.
The choice depends on your team and the project you are doing. If your team can't really see what benefits GWT will bring to the project, then you shouldn't use GWT.
Our enterprise-level application utilizes both and we're quite happy with the results. GWT is a powerful toolkit which lowers development time by orders of magnitude. That said, there are still things that GWT either doesn't handle all too well or just plain isn't suited for (and that's ok... that's why Spring MVC lives nearby). We have GWT-RPC hitting Spring services directly and it works incredibly well.
Our project though is a true webapp, not a website. We use a unified design which spans all "pages" (using a DockLayoutPanel and swapping out just the center makes this super easy).
IMO, whoever told you that GWT isn't good for consistent design across numerous "pages" is nuts...
I think any assertion that GWT (or any other method) lowers development time by an order of magnitude has already been debunked by Frederic Brooks in a time when shoulder pads and Jan Hammer's synthesizer were fashionable: http://en.wikipedia.org/wiki/No_Silver_Bullet.
But seriously, if you're a PHP shop, moving to 100% Java would be a huge investment, and not to be taken lightly.
On my experience of GWT, my only bad experience was with GWT compilation slowness due to lot's of permutations. Our application had more than 20 languages to support, which multiplied by 6 for browsers specific result in 120 permutations, which proved to get horrible performance.
But this is not a real bug issue, because you'll mainly use the dev mode, with instant code update, and you can have special compilation unit with reduced set of browser and language (even one language and one browser => one permutation if you wish).
So in my case, using Jenkins we made the big prod target full build nightly, deploying on a QA platform so that the QA team test every browser language combination. And on every commit a reduced build (1 browser and 2 languages in our case) was deployed on a dev validation platform.
GWT is definitively a great tool for large app. ;)
I'm interested in how to develop Web-GUIs using test-driven-development.
Especially I'd like to know if there are any guidelines/hints/best-practises on how to design Web-Frontends (i.e. the HTML) in order to be (automatically, of course...) testable? (in classical UI-developement there are patterns such as MVVC which support TDD and automated testing)
The are very similar patterns for web development as there are in desktop development. But, and it is a big one, the web is stateless. This sounds obvious but I think it clearly defines the boundaries for testing.
There are many, many popular incarnations of MVC for the web. However, in some web technologies it is hard to separate out pure UI (HTML, CSS etc) from code. You can always fall back on more of an MVP approach, which is like MVVM except the view is passive (won't respond to events and rebind). These patterns should cover you for the main UI logic of the application. All of these patterns can be used with TDD.
If you want to then go up a level, you are into tools like Selenium. These tools allow record/playback of user interactions with the web ui. However, if used casually, they can lead to brittle tests that break when the layout changes.
Hope this helps.
I don't know of any specific guidelines, but writing clean, semantic HTML and making appropriate use of CSS class and IDs is normally sufficient.
I have been using Dojo and Dijit for more than a year to develop a browser-based IDE. Dojo is a great framework. But creating an IDE-like interface using Dojo is cumbersome and wastes a lot of time unless you are a CSS superman. I have a good understanding of HTML5, JavaScript, and CSS. Building the UI I needed required several CSS hacking that I found by trial and error. There was no systematic way to get from the UI design to the implementation and I am afraid to change the UI layout because any simple change can break the UI, mostly by adding irrelevant scroll-bars to Dijit panes where I do not need them. (the complex UI has 4-5 levels of nested panes including mostly border containers and content panes)
Recently I have come across SproutCore and Cappuccino, which have great demoes and their look and feel is more desktop-based. There has been several discussions comparing these two with each other. But none of them talk about how systematic and quick is it to get from UI design to implementation? Ideally, I should be able to implement the UI I want not more than a couple of days (Assuming that I know the framework), and changing them in the future should be easy.
The other difficulty with Dojo is that I have to work directly with DOM, to append and remove dijit widgets. While I do like to keep this flexibility, I wish I could use a higher level of abstraction to define the application UI. I have read about MVC in SproutCore and Cappuccino, but I am wondering if in practice the provided abstraction layer speeds up the UI development? or the provided layer is a fancy architecture that only increases the readability of the code? Will I lose the direct access to DOM if I build my UI using these abstractions?
Cheers,
Navid
Cappuccino is much higher-level. You write in Objective-J, not HTML/CSS/JavaScript. I personally do not recommend it as Objective-J is a niche language and you'd be stuck with something not widely-understood by everybody. You'll find it more difficult to look for answers to problems, and other people will have more difficulty in maintaining your code.
However, due to it being high level, it does shield you from the drudgery of programming in "standards" (i.e. HTML/CSS/JavaScript). Therefore, you should be able to develop UI's faster and easier, but you'll have to instead learn the ins-and-outs of Objective-J. All-in-all, not much to gain here, I suppose.
SproutCore, on the other hand, is HTML/CSS/JavaScript based, so you don't really have to relearn the basics. It follows the MVC model of separating UI and data concerns, so programming UI's should be easier.
My personal recommendation is to stick with Dojo -- 1.6 has come out, which has change-tracking, state-tracking and bining support. 1.7 is around the corner. The MVC module is improving fast. The next version, 2.0, will be quite awesome. It is being actively developed on, and so you won't be left behind.
Dojo can also be used with the Closure Compiler's Advanced Mode to make highly-compact, highly-optimized, fully-obfuscated builds for deployment. Other JavaScript-based frameworks are not as adaptable.
Cappuccino most definitely goes beyond just improving readability. If you don't want something to have a scrollbar in Cappuccino, don't give it one. That's pretty much the end of the story and one of the great advantages of using such a framework. In my experience, HTML and CSS is just an endless troubleshooting session. With Cappuccino things go where you say they should and stay there. And this is true across browsers as well (most of the time).
Furthermore you can, if you choose to, build your user interface using Interface Builder and Cappuccino's nib2cib utility. This makes it trivial both to initially lay out and to then later shuffle buttons and controls around.
Have you considered jQuery and the jQuery UI?
I came accross the term Modular Extension as a requirement of an application of I am developing. Any body know what a Modular Extension is all about?
In general, if something is modular it means it's independent to the rest of your application, so that you can switch it on or off as needed, or remove it entirely, without affecting other things.
If something is an extension it means it's not considered a core part of your application, but rather separate functionality that can be developed on its own. Usually, the ability to write extensions implies a relatively well thought-out design and a sophisticated API that allows outside clients to get at the relevant internals of your core application.
Otherwise, though, your question is a little too generic to give a precise answer without more information.